. NET application Architecture design-work cell mode (the important idea of getting rid of the process code, attacking DDD)

Read the catalogue:

• 1. Background information
• 2. The real dilemma of procedural code
• 3. A simple example of the work cell pattern
• 4. Summary

1. Background information

has been talking about object-oriented development, but the biggest problem with object-oriented development when developing enterprise applications is that interoperability between multiple objects involves database operations. Two business logic objects need to be called to each other, and if the interaction is within the scope of a business transaction, it is easy to complete, but if the business logic operation involves multiple business objects working together to complete the problem.

In the past, we used procedural Code (transactional scripting mode) to write all the logic related to this business transaction in a large code, even if you properly extract duplicate code, the effect is not very good, because you can never get rid of the multi-object operation of the dilemma. How to confirm if you are in this predicament, you just have to look at the entry of all your transactional operations there is only one business method. For example, when you add an order, you also take the items followed by the order in the "Add order" method, rather than in another "Add Order Item" method, these two methods are located in different table module classes.

This chapter describes a pattern that is designed to coordinate multiple business objects within a business transaction to ensure a complete transaction when developing enterprise application systems.

2. The dilemma of procedural Code

In fact, the most important difference between developing an application system and developing a framework or component is to consider the persistence of the data, while the persistent logic is closely related to the business logic, and the last action of a method may be to add a row of data or update a field. Rather than application-system code, it is often the last time to flush the final persisted files uniformly, and there are few transactional data operations in such programs. Even if there is, the use of memory transaction processing is relatively simple, do not need to consider so many service-side things.

I have written a lot of components, frameworks, although not anything complicated, but to my experience and sentiment is how to use its meticulous design granularity in enterprise application system, how to carry out complex and meticulous oo design development. In fact, if we can not break the pattern of process-style code, then see more oo knowledge is also weak, but will let you produce a lot of negative emotions (because I have this experience).

In fact, we still lack the correct method, this article Unitofwork mode will help us out of the process of business logic, to the minimum object-oriented development. With Unitofwork you can use the table module, Activa Record, domin driven mode as you wish, and you can do SOA partitioning on a large layout based on your project needs (CQRS), Let the patterns play their best in their respective scenarios.

3. A simple example of the work cell pattern

Here we still use a simple order shopping business as an example, after all, we all understand this part of the business concept. The business layer of this instance uses the active record mode.

namespace ordermanager.business{    using System.Collections.Generic;     public partial class Order    {public        long OId {get; set;}         Public list<orderproducts> Products {get; set;}}    }

the field portion of the Order activity Record object.

namespace ordermanager.business{public    partial class Order    {public        bool Checkorder ()        {            // Perform partial business validation work            if (this. OId <= 0) return false;             return true;}}    }

The order activity Record object body, used purely for demonstration purposes, contains a simple judgment business logic.

namespace ordermanager.business{public    partial class orderproducts    {public        long OrderId {get; set;} Public         long PId {get; set;}         Public float price {get; set;}}    }

Order item section field.

namespace ordermanager.business{public    partial class orderproducts    {public        bool Checkproducts ()        {            //Perform partial business verification work            if (this. OrderId <= 0) return false;             return true;}}    }

Each product contains its own logic validation.

Let's take a look at how the application-level portal approach coordinates business operations and data storage between two active record objects.

namespace ordermanager{using Ordermanager.business;     Using Ordermanager.datasource; public class Ordermanagercontroller:controllerbase {public bool AddOrder (order order) {USI Ng (unitofwork unitofwork = new Unitofwork ()) {order. Checkorder ();//Perform business check order. Products.foreach (item = {item).                Checkproducts ();//Perform a business check of each activity record object, which can also be handled using the table module.                 });                Ordergateway Ordergateway = new Ordergateway (unitofwork); var orderdbresult = Ordergateway.addorder (order);//First database table operation Orderproductsgateway Productgateway = new Ord                Erproductsgateway (unitofwork); var productdbresult = productgateway.addorderproducts (order.  products);//Second database table operation if (Orderdbresult && productdbresult) {if                    (Unitofwork.commit ()) {this. SendorderintEgrationmssage (order);//Send successful Integration order message return true; } this.                Pushorderprocessqueue (order);//Send this order to the processing queue return false; } this.                Logbusinessexception (order);//Record a business handling Exception Log for troubleshooting.            return false; }        }    }}

To illustrate the example, I use an instantiated approach to construct data access objects, which can be injected dynamically using the IOC tool in practice.

Let's take a look at the data layer code, the data layer I use the table entry mode.

namespace ordermanager.datasource{public    abstract class Gatewaybase    {        protected unitofwork unitofwork { Get Private set; } public         gatewaybase (unitofwork unit)        {this            . unitofwork = unit;        }         public bool Commit ()        {            return this.UnitOfWork.Commit ();        }         public void Rollback ()        {this            . Unitofwork.rollback ();}}}    

This is a table entry base class.

namespace ordermanager.datasource{    using Ordermanager.business;     public class Ordergateway:gatewaybase    {public        ordergateway (unitofwork unit): base (unit) {} public         bool Ad Dorder (Order order)        {            //Here you can use the familiar way of splicing SQL to manipulate the database directly without an ORM.            return True;}}    }

namespace ordermanager.datasource{    using Ordermanager.business;    Using System.Collections.Generic;     public class Orderproductsgateway:gatewaybase    {public        orderproductsgateway (unitofwork unit): base (unit) { } public         bool Addorderproducts (list<orderproducts> products)        {            //Here you can use the familiar way of splicing SQL to manipulate the database directly, Without the need for an ORM.            return True;}}    }

This is two table entry object, in fact, this part of the code is familiar to everyone, so I omitted here, you can directly splicing SQL statements to insert the database.

namespace ordermanager.datasource{    using System;     public class unitofwork:idisposable    {public        void Dispose ()        {            throw new notimplementedexception ();        } public         bool Commit ()        {            return true;        }         public void Rollback ()        {            //        }    }}

The Unitofwrok object is actually the encapsulation of the System.Data.Common.DbConnection object of the database object, where you can construct the database connection object and open the transaction using the familiar way.

In fact, we appreciate the application of the code in the controller, here very coordinated processing of the various logic, finally recorded some necessary logs and send some integration messages. Did you find that you could handle some of your business systems without using DDD?

4. Summary

Active record mode + table entry mode + work cell mode, I actually think that I can handle small and medium business logic very well, with the SOA architecture now, there are very few projects in one solution.

Finally the sentence, provide a reference material, if interested can further communicate the specific design, because of the time relationship article here, thank you.

King Qingyue Culture

Source:http://blog.csdn.net/wangqingpei557

This article is copyrighted by the author and Csdn, welcome reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.

. NET application Architecture design-work cell mode (the important idea of getting rid of the process code, attacking DDD)