Summary:
This article introduces the structural framework of Duwamish online electronic bookstore routines, and analyzes the number of features and design patterns of this structure.
Introduction:
As an example of Visual Studio .NET, Duwamish must contain some information that Microsoft .NET design team wants to communicate with developers, in fact, Duwamish can indeed referred to as a classic .NET developer Examples, whether it is from its design architecture, programming skills, or code style, there should be a standard .NET enterprise application should have characteristics. Therefore, by studying the example of duwamish, the master can understand the design idea of the .NET application architecture, and the low hand can learn the programming skills of .NET, it is really old. :)
However, this purpose is more for intermediate .NET learners, such readers are often familiar with C # or vb.net syntax, which will use some basic class libraries and have some smaller program. But when they started to develop a real-level application that truly practical value, there is a feeling of indulgence. If you are in such a learner, please follow me in the world of Duwamish, I believe you will gain.
Duwamish introduction:
MiCrosoft companies launch new technologies, always launch some application examples of public code to illustrate the characteristics of the new technology, and developers can also quickly master new technologies through the code of this example. With the purpose of implementation. Microsoft demonstrates the most popular e-commerce companies in typical online shopping practices to customers (B2C) patterns, including member qualifications, accounts Basic features such as management, shopping carts, search and checkout processes. Duwamish has experienced three versions 4.0, 5.0, and 7.0, each version of the release of technology progress, and each version represents the most advanced technology trend at the time. It will be to study and discuss the highest version of DUWAMISH, experienced COM / COM technology and DUWAMISH of the Microsoft DNA architecture, which is completely .NET technology and architecture in the latest version, more advanced and mature than before.
If you have installed Visual Studio .Net, you can find and install it in your VS.NET's Enterprise Samples directory, for example: c: / program files / microsoft visual studio .NET / Enterprise Samples /, or you You can also go to the http://astradigital.com/duwamish7vb/ this address to see its presentation instance in the Internet. Other details of Duwamish, please refer to the MSDN help included with Visual Studio .Net, address is: ms-help: //ms.vscc/ms.msdnvs.2052/dwamish7/html/vtoriduwamishbooks70.htm, no more details here.
DUWAMISH Structure Analysis:
Duwamish 7.0 is a typical N-layer architecture that is divided into four logical layers:
Web layer
The Web layer provides the client to access the application. This layer is implemented as a Web project in the duwamish.sln solution file. The Web layer consists of an ASP.NET web form and code hidden file. The web form is just a user operation with HTML, and the code hidden file implements event processing of various controls.
Business appearance layer
The business appearance layer provides the web layer to provide processing accounts, category browsing, and books. This layer is implemented as the BusinessFacade project in the duwamish.sln solution file. The business appearance layer is used as an isolation layer that isolates the user interface to the implementation of various business functions. In addition to the low-level systems and support functions, all calls to the database server are made through this assembly. Business rules
The business rule layer is implemented as the BusinessRules project in the duwamish.sln solution file, which contains various business rules and logic implementations. Business rules complete this task such as the verification of customer accounts and book orders.
Data Access Layer
The data access layer provides data services for the business rules layer. This layer is implemented as a DataAccess project in the duwamish.sln solution file.
It is more confusing that the business appearance layer and business rule layer have been studied when studying the N-layer structure development, which is: representation of layers, intermediate layers, and data layers, respectively. Duwamish's Web and data access layers are better understood, that is, the representation layer and data layer in the traditional sense, then what is the connection between business appearance layers and business rules and our familiar intermediate?
Design ideas:
In a web application, some operations are just simple from the database to extract data according to the conditions, and do not need to pass any processing, and directly display the data directly on the web, such as a list of books. Other operations, such as calculating the total price of books in the order and calculating a rebate according to customer level, etc., this part often has many different functions, and it is more complicated. We can imagine it first. If we use a three-layer structure, these business logic will generally be placed in the middle layer, then the internal and large varieties of the internal, and the use of different types of calling tasks are all completely settled. Indicates the layer. This will increase the amount of code that represents the layer, complicates the task of the layer, and the indication layer is only responsible for accepting the user's input and the task of returning the result is not commensurate, and increasing the degree of coupling between the layers and layers.
In order to solve this problem, let's first look at the description of the FACADE mode in the "Design Mode":
To provide a consistent interface for a set of interfaces in the subsystem, the FACADE mode defines a high-level interface, which makes this subsystem easier to use.
Applicability:
When you want to provide a simple interface for a complex subsystem. Subsystems tend to become more complicated because of continuous evolution. Most mode uses more smaller classes. This makes the subsystem more reusability, and it is more easier to customize the subsystem, but this also brings some difficulties to those users who do not need to customize subsystems. FACADE provides a simple default view that is enough for most users, and those users who need more customizable can cross the FACADE layer.
There is a lot of dependence between the client program and the abstract class's implementation. Introducing FACADE to separate this subsystem from customers, and other subsystems, can increase the independence and portability of the subsystem.
When you need to build a hierarchy subsystem, use the FACADE mode to define the entry points of each layer in the subsystem. If the subsystem is interdependent, you can make them communications with FACADE, which simplifies the dependence between them.
This contradiction, justice, justice and design mode, the problem that needs to be solved in Facade mode is very consistent, the solution proposed in "Design Mode" is to introduce a FACADE object, let this façade are managed The internal class of the system provides a single and simple interface for the representation layer. This façade object, in our duwamish design, is the businessfacade layer.
We can clearly see from the figure, the browser first calls the layer web, then the web will request the request to send to the business appearance layer, the business appearance layer is preliminary processing, and it is necessary to call the business rule layer. Still directly call the data access layer to obtain data. Finally, the data access layer accesses the database and returns the result to the browser in accordance with the procedure (for other structural modules, respectively). Code example:
The following is a code example of two different processing paths:
Get product catalog
Productsystem = new productSystem ();
Categoryset = ProductSystem.getcategories (CategoryID);
The business appearance layer directly calls the data layer:
Public CategoryData getcategories (int CategoryID)
{
IF (dscommand == null)
{
Throw new system.ObjectdisposedException (gettype (). fullname;
}
Return FillcategoryData ("Getcategories", "@categoryid", categoryID;
}
Add orders
Public void addorder ()
{
ApplicationAnssert.checkcondition (CartorderData! = NULL, "Order Requires Data", ApplicationAsetrt.LineNumber;
ApplicationLog.writetrace ("duwamish7.web.cart.addorder: / r / ncustomerid:
CartorderData.tables [OrderData.customer_Table] .rows [0] [ORDERDATA.PKID_FIELD] .tostring ());
CartorderData = (New OrderSystem ()). Addorder (CartorderData);
}
Business appearance layer calling business rules:
Public ORDERDATA Addorder (OrderData Order)
{
Applicationassert.checkcondition (ORDER! = NULL, "Order is Required", ApplicationArt.LineNumber;
(New BusinessRules.Order ()). InsertORDER (ORDER);
Return ORDER;
}
Business rule layer invoking data layer:
Public Bool InsertOrder (OrderData Order)
{
/ / Omitted complex processing logic here
IF (isvalid)
{
Using (DataAccess.OrDERS ORDERSDATAACCESS = New DataAccess.OrDERS ())
{
Return (OrdersDataAccess.InsertorderDetail (Order))> 0;
}
}
Else
Return False;
}
Summary:
