Discuss the traditional and new layers, or the DDD Layers

Address: http://www.cnblogs.com/virusswb/archive/2011/01/10/1931964.html

 

Introduction

The layer mentioned in this article is only the layer of the software architecture. The traditional hierarchy refers to the traditional three-layer structure: UI (interface presentation layer), BLL (business logic layer), and Dal (data access layer ). All the points put forward in this article are personal understandings and have nothing to do with any organizations. If you have any objection, please make a good decision.

Of course, these problems may be my personal problems, but they do not mean that everyone exists. If you have no, please do so. If it's a personal problem, let's take a look at it.

The traditional layering mentioned here may also be caused by my incorrect understanding of layering, but what I see is not just the structure of my project, many projects are structured like this. InsideCodeAs I understand it, at least it can be explained that some people have made the same mistake as me.

 

Traditional layering

 

The biggest problem with traditional layering is that it splits the relationship between the upper and lower layers, turns the relationship between them into simple interface calls, and turns it into full interface formalism. At the same time, it is ignored that the lower layer provides services for the upper layer, rather than independently. The services provided by the lower layer should be governed by the upper layer. Of course, it does not mean that more services cannot be provided, but at least the upper layer should be provided, and then some "edges" should be considered ".

Let's first look at a traditional hierarchical solution structure.

The reference relationships between them are: Ui references Bll, entity, and common; BLL references idal, entity, and common; idal references entity; Dal references idal, entity, and common.

Show row number Copy code ? UI code

1.   private void  button#click ( Object  sender,  eventargs  E) 
    

2. {< br> 

3.  _ 02_bll.  orderbll  orderbll = Common.  servicelocator . loadservice <_ 02_bll.  orderbll  (); 
    

4.  orderbll. submitorder ( New  _ 05_entity.  orderentity  () 
    

5. {< br> 

6.  orderseqno =  "123" , 
    

7.  orderamount = 1000 
    

8. }); 
    

9. }< br> 

When the upper layer calls the lower layer, it does not need to call the lower layer. Instead, it filters out some services that can be used from the lower layer. If you find that you are not ready to use it, add one to the idal file and implement the following in the Dal file. Now, BLL can be used. This will also lead to the blind Implementation of bll in the development of the Dal layer without fully considering the needs of BLL. Then, when BLL is used, it will find that many of them have to be rewritten. This results in a large waste of code, manpower, time, and energy. It will also affect the development progress.

 

New Tiering, or DDD Tiering

 

It is a new type of hierarchy. I read some of the DDD in the blog Garden during this time.ArticleAnd the source code of the two projects nlayerapp and smartca on codeplex. After reading this, I have some understanding. Whether it's like it or not, I think it's a little bit more reasonable than the traditional layering. I just shared it and earned some popularity. I am cheating on clicks, haha.

Let's take a picture first.

The layers in DDD are mainly four layers: Presentation (presentation layer), application (Application Layer), domain (domain layer), and infrastructure (basic layer ).

Presentation is equivalent to the previous UI Layer. Application is the scheduling layer of a task. It does not have actual business logic and is not recommended to be put into the business logic. In practice, it can be replaced by WCF or a common class library. In fact, it is called Based on the UI business and then mapped to a specific domain object. Application can also be used to expose coarse-grained business processing, because the business processing at the domain layer is fine-grained. Without the previous Dal, place its part in the infrastructure layer.

The previous idal is put into the domain. In the figure, it is the domain. Core Project, which will be referenced by infrastructure. Because the idal in domain. Core is equivalent to the requirement of the domain object for persistence, that is, these functions must be implemented, which are required by the domain object. The specific implementation, persistence, persistence to relational databases, file systems, or memory databases are defined by the specific implementation. That is, the infrastructure. Data. Core and infrastructure. Data. mainmodule projects in the figure. The implementation of these two projects is all required for the persistence of domain objects, and there will be no major loss of unnecessary methods. I don't know if this is an improvement?

 

Conclusion

The traditional hierarchy, or the traditional hierarchy that I understand, has the problem of the relationship between the split layers, which formalizes the relationship between layers. The upper layer has no need for the lower layer, and the lower layer serves the upper layer. The hierarchy of DDD can solve this problem, which will improve development efficiency and reduce detours.

I don't know how everyone knows this ???????? We look forward to your reply.

[Blog]Http://virusswb.cnblogs.com/

[MSN]Jorden008@hotmail.com

[Note] Please indicate the source for reprinting. Thank you.