Application System Architecture Design

Original: http://www.cnblogs.com/simonw/archive/2005/04/27/146185.html

We are doing on the surface seemingly for a variety of different applications of development, in fact, behind the corresponding architectural design is relatively stable. Programming in a good architecture, not only for developers is a pleasing thing, but more importantly, the software can show a healthy posture, and the unreasonable architecture design, not only to the suffering of developers, the software itself life cycle is seriously threatened. Here I will do a superficial discussion on the general architecture process design of the application development system on the Microsoft Dotnet platform.

General design drawings

Presentation Layer

The presentation layer consists of UI (User Interface) and UI control logic.

L UI (User Interface)

The UI is the client's user interface, which receives commands, requests, data from the user, passes to the business layer for processing, and then renders the results. Depending on the client's differences, we generally divide the application into BS (browser-server) browser structure, CS (client-server) desktop client structure.

BS has the advantage of not having to worry about the client, just deploy the maintenance server. CS's advantage lies in the strong interface interaction expression ability. RIA (Rich Internet application) is a technique for merging the advantages of both architectures, which relies on a client-side installation of a common interpreter to gain strong interface interaction and ease of deployment without deploying a specific client. A lot of specific implementation technology, such as Microsoft's SmartClient, Avalon Macromedia Flex, JS based Bindows;ajax and so on.

L UI Control logic

The UI control logic handles the data interaction between the UI and the business layer, controls the state flow between the UI, and is responsible for simple data validation and formatting functions. Specifically, under the Dotnet event-driven programming model, the UI control logic is naturally implemented in event functions, such as Pageload event functions, ButtonClick event functions. In these event functions, the main task is to do the data exchange and business invocation between the UI control and the business entity, but it becomes the biggest problem in the face of a large amount of data exchange workload and maintenance. In a complex application system, the management of state and process is the factor that must be considered, they are also part of the business logic, if not encapsulated directly in the event function will cause the business dependency representation layer. These two issues are discussed separately below.

1.1.UI data interaction with business entities

The business entity that is responsible for data exchange at this stage is called the DTO (data Transfer Object), where we populate the DTO with the data from the UI control and then propagate it down, processing the output, and the user makes the request the business layer returns the data as a DTO and assigns it to the UI control to show. Therefore, a way is needed to automatically resolve such a round-trip assignment problem. Unfortunately, many of the controls under Dotnet, while supporting data binding, still do not have a ready-made, complete solution. We can design a adapter on our own. This kind of binding is handled automatically by a mapping relationship, preferably a prior naming convention for UI controls and Dto properties, in which case the Convention as a mapping relationship does not require any additional configuration files and configuration work.

2.2. State and process Management

Since it is part of the business logic, it should not be coupled to the presentation layer. The MVC (Model-view-controller) pattern provides a way to achieve this goal. Controller is the core of the entire solution, a process manager, in which all commands and data from the UI are controller to the business layer or other UI, so that we can encapsulate the logic of processes, permissions, etc., such as configuration files, to maximize business reuse. Dotnet under the MVC scheme does not have as many options as Java, there are several options available:

Microsoft's uipab, it can handle bs,cs under the process jump, can make the same business system has webform and WinForm different presentation.

Open source Mavrick.net, it only applies to the ASP.net application, it provides a good support for process, internationalization, page wrapping, XSLT page conversion.

Open source Lattis, the same applies only to ASP.net applications.

Business Layer

Business layer encapsulates the actual business logic, including data validation, things processing, authority processing and other business-related operations, is the core of the entire application system. Therefore, it is necessary to design a business layer that can reflect the actual needs, and we divide the actual business into two parts: business data and business operation.

L Business Data

Business data is the core of the business logic, the final business data will be in a fixed format in memory, in the system between the various levels of transmission, as a dto role. The way to express business data is generally divided into two kinds of table model and domain model.

Table model is to map the tables in the database directly into the business data objects, such advantages are suitable for machine operation, ADO. NET provides the convenience of this kind of operation directly, but the expression of complex business relation is very not intuitive. It is only suitable for situations where business requirements and data tables are directly related to the need for rapid development. Typically, we select a dataset or a strongly typed dataset (strong Typed DataSet), which supports type checking at compile time and is more efficient than a regular dataset. The dataset has many handy features: it does not need to write maintenance classes, support serialization, data copy preservation, support data collection, support for control binding, Microsoft provides the corresponding build tools and durable solutions. But the disadvantage is also obvious, complex data performance is not intuitive, as a dto in all levels of transmission, especially the distributed environment, the large volume, relatively slow instantiation of the performance caused by a lot of pressure.

Domain model is based on the actual business in accordance with the realistic method of Oo thought modeling, so it is suitable for complex business systems. It is usually expressed in the form of a custom data entity (Entity). Custom data entities, with good performance, compile-time type checking, data representation is very intuitive to meet the actual operation of the business and other advantages, but need to define their own maintenance classes, in a distributed environment to write their own serialization methods.

Comprehensive factors to consider, although the business simple corresponding to the direct system we use the table model modeling and development efficiency is very high but inevitably ensure that the system will not become complex, so for reuse, scalability, performance and other aspects of domain model selection model is preferred.

L Business Operations

Business operations are responsible for a variety of business related processing of business data, such as validation, flow, integration, things, permissions, etc., but it is not responsible for the operation of the data source. Its relationship with business data is designed in 2 ways.

Separating business data from business operations and encapsulating business data separately into data classes that only have data get,set, the data class serves only as a dto. Encapsulates business operations into separate service classes and acts as a business layer with business data. In this way, when the system is not complex, the simple and intuitive, and as the system becomes more complex, service class will become messy, and the coupling of the data and operation of the separation of the complex is also an unfavorable factor. Specifically refer to Martin Fowler's anemic domain model, but I'm not inclined to direct access to the data source at the business level.

The integration of business data and business operations, the business data and related business operations packaged together called business entities, business entities as a unified business layer for the presentation layer to provide services, but also responsible for the DTO at all levels of transmission, I prefer this complete domain model design method, Each business entity can exist as a single component, which is of great benefit to component reuse.

• Dependencies between business modules

Dependencies between business modules can sometimes be difficult to solve, especially for reusable business components such as rights management, mail delivery, and so on. Managing these various business components is our goal, and the IOC container provides us with the perfect solution to inject different modules into the system that we can invoke without knowing that the component exists. But at present only immature spring.net a choice, we have only one sigh, therefore also not much discussion.

Business Data Access Layer

The Business data access layer is an exclusive layer for the specific application system, it provides the business layer with the minimum operation mode of interaction with the data source, only the data access interface required by the business layer, and the business layer relies entirely on the services provided by the Business data access layer. These services are responsible for receiving data from the business layer or returning to the business entity, which masks the difference between the actual business data and the way the machine is stored. Of course, the data layer to choose the abstract solution can also achieve this effect, but the business data access layer is the most characteristic of the specific business to do the abstract, and the abstract data-tier access scheme is for general to do abstract. Often in the business for specific design vitality will become stronger, this allows us to maximize the reuse of upper-level code, and when a storage policy needs to be replaced if the data-tier access is too different, and the problem is not resolved by replacing the data tier, we need to change the business data access layer at most, without changing the business layer.

The Business data access layer consists of the DAO (data access Object) layer and the system service layer. The DAO layer provides the most basic data access service for each business entity, and the system service layer provides the system global with a common data access service that is not business-related, and the two tiers are at the same level in the system.

Business layer and business data Access layer diagram

Data Tier

The purpose of the data tier is to provide an interface for the data source to be accessible to the outside world, it is easy to migrate to a different data source by choosing a data-tier component that provides an abstract data source-independent data access interface and accesses the data source by hooking up a variety of dataproviador under it. There are currently 3 types of data-tier scenarios:

1.1. Encapsulation Ado.net

These data access components are based on ado.net shallow encapsulation, its advantage is that the encapsulation level is low so the fastest, we can manually organize SQL statements to adapt to complex operations and personalized optimization. The disadvantage is that business entity objects that cannot be processed directly from a custom data entity need to be passed in as arguments in the data attributes in the business entity. This way although the most insurance, but with the scale of the system, development efficiency, quality, and later maintenance, two development has become a particularly prominent problem, the requirements of developers will become more and more high. In addition, the operation of things is not very good encapsulation, can not provide declarative things, often in the business layer of the need to access the data tier. Such components are currently widely used, such as the Daab (Data Access Application Block) that Microsoft provides in Enterpriselibrary, as well as previous DAAB3.1. Enterpriselibrary is a mature product, including data access, exceptions, logs, caching, encryption, configuration, security and other components as a universal service is very suitable.

2.2. Or-mapping components

ORM is the best data persistence solution, with the advantage of being able to manipulate data in an object-oriented manner, so that you can directly handle the business object of a custom data entity, and we don't have to worry about SQL statements and underlying storage, so that the most streamlined code increases development efficiency, Great convenience for future maintenance of extensions. The disadvantage is that shielding the bottom so that we can not be optimized for specific data sources, and for complex associated SQL operations are somewhat powerless, while performance is also poor but the helper to cache the situation will be much better, and in the dotnet the biggest problem is not a mature and cheap ORM products for our use, All are beta and commercial editions. These editions are more or less problematic, so that the real application needs careful examination. such as nhibernate,gentle.net,xpo,grove.net and so on are very many.

3.3. Datamapper (Sqlmapper)

Sqlmapper provides a tradeoff between the two ways in which you can directly process the business object of a custom data entity in an object-oriented manner, and execute handwritten SQL statements based on the mapping relationship to the data source and business entity, so that we can optimize for specific data sources. The same can be done for complex operations. At present only ibatis.net a product, it is a Java to move open source project, already more mature, can replace DAO freely without compiling.

Now that the discussion of the entire architecture scenario has been completed, we can see that the dotnet solution is so limited, looking back at the Java world, with so many mature and available component frameworks, drooling ... But dotnet is also maturing, and we need time to wait. The idea of this architecture design only represents my own understanding, and it is not that all development is such a set of programs, in the specific environment needs to make specific adjustments. Hope to play a role in the action. My mailbox is I-simon at MSN.com, due to my experience is shallow, there are incorrect or insufficient to welcome the discussion, in addition, this article will continue to update according to the latest progress of technology.