Finally, you get to the VS .NET Integrated Development Environment (IDE). To begin, load VS .NET. Once it loads, follow these steps:
Select File New Blank Solution. Name the solution Northwind. This creates an empty solution with no files, and the IDE will be empty.
Now you need to add the individual projects to the solution. Select File Add Project New Project. Select the Class Library project type, as shown in Figure 2-3. Enter the project name as NorthwindDC.
Figure 2-3: VS .NET New Project dialog box
Repeat the previous steps to add two more class library projects, one called NorthwindUC and another one called NorthwindShared.
Now, add a Windows Application project called NorthwindTraders. Later on you will learn how to put a Web frontend and Web services frontend onto your application.
Next, right-click the solution (at the top of the Project Explorer window), select Add Add Existing Item, and browse to the Northwind directory that contains the web.config file. Select web.config and click Open. VS should now look like Figure 2-4.
Figure 2-4: Visual Studio, Northwind solution
Right-click NorthwindTraders and select Set as Startup Project. This causes this project to launch every time you run the application from within the IDE. Once you are done with this step, the NorthwindTraders project will be bold in the Solution Explorer.
Now you need to set up the application namespaces. Namespaces are a feature of .NET that allows the developer to control where classes are referenced from within code—regardless of where the class actually resides. For example, if there are two separate blocks of code that exist to handle errors, and these blocks of code are in different assemblies, you can make that fact transparent to yourself and other developers through the use of namespaces. It is also a great way to group functionality within your application, exactly as Microsoft did with the .NET Framework base classes. For example, everything related to input and output is located in the System.IO namespace, even though the code may be located in many different assemblies. There are two different places to enter namespace information, and they are generally used in conjunction with one another. Right-click the NorthwindDC project and select Properties. Figure 2-5 shows the properties for the NorthwindDC project. Make sure that Common Properties, General is selected from the tree view, and you will see a textbox for RootNamespace, which currently reads NorthwindDC. Change this to NorthwindTraders.NorthwindDC and then click OK.
Figure 2-5: NorthwindDC general property page
Break up your code into logical units of functionality using namespaces. It makes it easier for developers working in teams to find specific blocks of code. Create your namespaces using a common naming convention such as the following: Company.Division.ApplicationName. This will ensure that even in large organizations namespaces will never cross over each other. This will cause fewer problems when developers start reusing code from other applications.
Repeat these steps for the NorthwindUC and NorthwindShared projects so that the namespaces read NorthwindTraders.NorthwindUC and NorthwindTraders.NorthwindShared. You do not need to change the namespace of the NorthwindTraders application because its root namespace is already NorthwindTraders. The second place to change namespaces is in a code module, as shown in this block of code:
Namespace Errors Public Class ValueTooLongException Inherits System.ApplicationException Public Sub New() End Sub End Class End Namespace
If you added this namespace declaration in the NorthwindShared project, you would reference this code throughout the rest of the project by using the following line of code:
Because that would be a lot of typing to do every time you wanted to use the ValueTooLongException class, you can use the Imports keyword at the head of each code module to import the namespace, just as you would with any of the .NET Framework's namespaces. For now, you will not be adding any namespaces, but you will as you progress into the application.
The last step is to add all of the references you will need to create between your assemblies and to add two additional assemblies from the Global Application Cache (GAC). Expand the References node of the NorthwindDC project and you will see that the only references are System, System.Data, and System.XML. Right-click the References node and select Add Reference. This brings up the Add Reference dialog box, as shown in Figure 2-6.
Figure 2-6: Add Reference dialog box
From the .NET tab, select the System.Runtime.Remoting assembly by double-clicking it. Then, switch to the Projects tab, as shown in Figure 2-7.
Figure 2-7: The Projects tab of the Add Reference dialog box
From the Projects tab, select the NorthwindShared project by double-clicking it. Both of these components will appear in the dialog box's Selected Components list. Then click OK. This adds two more entries under the References node in the NorthwindDC project. You are not going to add any references for the NorthwindShared project, but you will need to add some references for the NorthwindTraders project. Right-click References in the NorthwindTraders project and select Add Reference. Then select System.Runtime.Remoting from the .NET tab, and from the Projects tab, select the NorthwindShared and NorthwindUC projects and click OK. And finally, in the NorthwindUC project, add a reference to the NorthwindShared project.
This completes the solution setup for the NorthwindTraders application. The resulting application architecture looks like Figure 2-8.
Figure 2-8: Northwind application architecture
If you have Visual Studio for Enterprise Architects, you also have Visio for Enterprise Architects. You can reverse engineer the solution to Visio by first selecting the solution in the Project Explorer and then, from the main menu, selecting Projects Visio UML Reverse Engineer. This will reverse engineer the solution into a UML diagram from which this static structure diagram was created. It will also add the Visio file to your solution under the Solution Items folder.
This is the logical view of the application; it does not address the physical distribution of the application because that will be somewhat different from what is seen here. Chapter 3, "Creating the Application Infrastructure," examines the physical object model for the application and moves right in to coding the application (after all, that is why you are reading this book, right?).
Every application should have a naming convention, which should be fully documented in the project's technical standards document. It does not even matter if this is different from project to project, but it must be consistent within the project.
The projects you have just created are named the way they are for specific reasons. The letters DC at the end of the NorthwindDC project mean that this component contains data-centric objects. The UC at the end of the NorthwindUC project mean that this component contains user-centric objects (both of these object types were discussed in Chapter 1, "Understanding Application Architecture: An Overview"). The NorthwindShared project contains objects that will be used (shared) by other components.
As you can see, the naming convention is straightforward. Too many applications use a cryptic naming convention, and it becomes difficult to understand the interactions or the purpose of the objects. Chapter 3, "Creating the Application Infrastructure," delves into how the applications components are used in conjunction with one another.