Start to study enterprise application architecture

Document directory

• Inter-Layer Interaction
• Database
• Top-level activity relationship diagram

I wanted to study the enterprise application architecture for a long time and never had time (too many things to learn. I really feel that time is not enough .....). the completion of the first phase of the project has taken a bit of time to recover, just to study the enterprise application architecture. The general architecture is divided into three layers (everyone knows, huh, huh): the UI Layer; business Layer; dataaccess layer; this is what I previously knew, but this is a general layer. If we add it, the abstraction layer, entity layer, service, Orm, there are also some secondary layers (in short, they are refined). It is not very clear how to standardize the naming and the relationship between the layers. Today I have read three articles, which are very helpful, according to the above introduction, we are going to download petshop, duwamish, Fitch and Mather for research.
The three articles are:
Http://www.cnblogs.com/rexsp/archive/2004/09/16/43815.aspx
Petshop
Http://blog.csdn.net/thebesghost/archive/2006/08/02/1008782.aspx
Duwamish
Http://blog.csdn.net/cngkqy/archive/2006/05/19/745229.aspx
Http://blog.csdn.net/cngkqy/archive/2006/05/19/745229.aspx

:
C: \ Program Files \ Microsoft Visual Studio. NET 2003 \ enterprise samples \ duwamish, Fitch and Mather
Petshop is searched on Google.

Today, we opened duwamish as an example. In vs, there was an "enterprise-level Panel project", which had already divided a project into seven layers: businessfacade (Business appearance layer );
Businessrules (Business Rule layer); dataaccess (data access layer); System (system framework layer); Web Service (service layer); Web/Windows UI (UI Layer );
Each layer can only complete its own tasks. If you use something that is not your own, there will be a warning (of course it will not affect System Operation)
The diagram of the relationship between each logical layer (from msdn) and its calling sequeance graph example:
The following is the entire call process for obtaining the description of category on the categories. aspx web page. (1) instantiate the productsystem object (2) Call the getcategories () method of productsystem (3) Check the validity of parameters (4) create categories: dataaccess object instance (5) return to the above object (6) Call categories: dataaccess object's getcategories () method (7) Create categorydata: common object instance (8) return to the above object (9) return categorydata :: common object instance, which contains the required data (10) returns categorydata: common object instance to the Web/client (11) to check the validity of data (12) read and display the result: Description of category

The systemframework project contains configuration parameters required by applications, applicationlog log classes, and applicationassert parameter verification classes. The systemframework project is referenced by all other projects. The common project contains datasets used to transmit information between layers. For example, the categorydata mentioned above inherits system. data. dataset is neither the so-called Typed Dataset nor the general dataset. It is simple and practical, and is based on. net remoting: a distributed system is developed to exchange data between tier and tier. Common projects are also referenced by other projects, except for systemframework projects. All the classes in the businessfacade project inherit the marshalbyrefobject class, which is obviously used to deploy businessfacade tier as remote objects. However, it is not actually deployed as remote objects by default, and the web layer still calls the local object (《 Duwamish Deployment Solution). 3 , SummaryWhen developing enterprise-level Distributed Systems Based on. NET Framework, the above architecture is worth recommending, but it is not flawless. In fact, there are some points worth improving. Obviously, it is impossible for an example to fit all the actual situations. The requirements are too harsh. In fact, the architecture of Fitch and Mather 7.0, another example of Enterprise samples, is somewhat different from duwamish. If you are developing a local system, do not imitate the duwamish architecture (you can see the process of calling the description obtained from the category above, which is too difficult .), For example, the classes in business facade and business rules should adopt the fine-grained interface design, and the interaction parameters between layers do not all need to use dataset. You can use setter/getter as appropriate, this not only improves development efficiency, but also improves performance, maintainability and reusability.
The following describes the petshope architecture:
The topic architecture is as follows:

The hierarchical design can achieve the following objectives: decentralized attention, loose coupling, logic reuse, and standard definition.

The system architecture of petshop4.0 is as follows:

In the data access layer (DAL), the Dal interface is used to abstract the data access logic and the Dal factory is used as the factory module of the data access layer object. For the Dal interface, the SQL Server Dal that supports the MS-SQL and the Oracle Dal that supports the Oracle are specific implementations, respectively. The model module contains data entity objects. The detailed module structure is as follows:

Figure 6: module structure of the data access layer

We can see that the "interface-oriented programming" concept is fully adopted in the data access layer. The abstracted idal module is independent from the specific database, so that the entire data access layer facilitates database migration. The dalfactory module manages creation of Dal objects to facilitate access to the business logic layer. Both the sqlserverdal and oracledal modules implement the idal Module Interface, which contains the select, insert, update, and delete operations on the database. Because of the different database types, database operations are also different, and the code is also different.

In addition to removing the downward dependency, the abstracted idal module only has weak dependencies on the business logic layer, as shown in:

Figure 7: module structure of the business logic layer

In Figure 7, BLL is the core module of the business logic layer. It contains the core business of the entire system. In the business logic layer, the database cannot be accessed directly, but must be accessed through the data access layer. Note that the data access service is called through the interface module idal. Since it has nothing to do with the specific data access logic, the relationship between the layer and the layer is loosely coupled. If you need to modify the specific implementation of the data access layer, as long as the idal interface definition is not involved, the business logic layer will not be affected. After all, the specific implementation of sqlserverdal and oracaldal have no relationship with the business logic layer.

This is because the asynchronous processing mechanism is introduced in petshop 4.0. The insert order policies can be divided into synchronous and asynchronous policies. The insert policies for the two are obviously different, but for callers, the interface for inserting orders is the same, so the ibllstrategy module is designed in petshop 4.0. Although the ibllstrategy module only provides a simple iorderstategy, it also provides an example and information, that is, in the processing of business logic, if there are diversified business operations, or possible future changes should use abstract principles. You can also use interfaces or abstract classes to remove the dependency on specific services. However, in petshop, because the business logic is relatively simple, this idea is not obvious enough. Because of this, petshop puts all the core business logic in a module Bll, and does not strictly separate the specific implementation and abstraction by module. Therefore, the call relationship between the presentation layer and the business logic layer is highly coupled:

Figure 8: module structure of the Presentation Layer

In Figure 5, auxiliary modules are also introduced at various layers, such as the messaging module at the data access layer, which provides the asynchronous order insertion function and uses MSMQ (Microsoft messaging Queue) technology. The cachedependency of the presentation layer provides the cache function.

Next we will introduce the architecture of Fitch and Mather:
The Fitch and Mather 7.0 structure is divided into three logical layers:

• User Service Layer (USL)

  The user service layer provides clients with access to applications. The web project under the enterprise-level template project (ETP) node in the Fitch and Mather 7.0.sln solution file implements this layer of functionality.

• Business logic layer (BLL)

  The business logic layer provides business logic for processing accounts, buying and selling stocks, and researching companies. The bll project under the enterprise-level template project (ETP) node in the Fitch and Mather 7.0.sln solution file implements this layer of functionality.

• Data access layer (DAL)

  The data access layer provides data services for BLL. The Dal project under the enterprise template project (ETP) node in the Fitch and Mather 7.0.sln solution file implements this layer of functionality.

In addition to the three logical layers described above, Fitch and Mather 7.0 also contains the enterprise-level template project (ETP) in the Fitch and Mather 7.0.sln solution file) shared functions encapsulated in the "public" project under the node. In addition, the general accounting module (GAM) is a COM + component, which is implemented in the form of a separate project in the Fitch and Mather 7.0.sln solution file.

Structure Diagram

Inter-Layer Interaction

The Fitch and Mather 7.0 structure allows you to use a variety of distributed or non-distributed deployment solutions. Because the. NET assembly and usl can be separately deployed, various deployment schemes are possible. Although these assembly can be physically deployed as any configuration, inter-layer interaction should be considered before the deployment scheme is selected for performance reasons. For example, the close interaction between BLL and Dal requires that these two units be deployed together. In contrast, BLL and usl are not closely related, so it is easy to deploy bll in a distributed manner.

Database

The generated Fitch and Mather 7.0 Dal requires SQL Server 2000. However, you can configure the gam com + component to use SQL Server 2000 or Oracle 8.0.

Note:When GAM is configured to use Oracle, the rest of the application must still use SQL Server 2000.

Database	Note
SQL Server 2000	In [install Visual Studio. net drive letter]: \ Program Files \ Microsoft Visual Studio. the stored procedure and architecture defined in the. NET 2003 \ enterprise samples \ fmstocks7 \ database \ sqlscripts \ directory.
In Oracle 8.0	In [install Visual Studio. net drive letter]: \ Program Files \ Microsoft Visual Studio. the stored procedure and architecture defined in the. NET 2003 \ enterprise samples \ fmstocks7 \ database \ oraclescripts \ directory.

Note:The Fitch and Mather 7.0 database is static and does not reflect the value of the current stock.

Top-level activity relationship diagram

The following high-level UML activity diagram describes the operations and selections that users can perform on the Fitch and Mather 7.0 web sites.

Note:This diagram is a standard UML activity diagram. For more information, see Unified Modeling Language (UML ).

Fitch and Mather top-level activity diagram

After reading the introduction of these architectures, we should be able to help us design the architectures that meet our own requirements. The above are just collected from other places, not our own things, I will sort out my ideas and post my ideas.