. NET application Architecture design-use active record mode instead of domain model mode

Read the catalogue:

• 1. Background information
• 2. A brief introduction to the domain model mode, Activity recording mode
• 3. Simple examples and key points of activity recording mode
• 4. Summary

1. Background information

Interested in the software development methodology, Bo Friends should find that the recent "field-driven design" has slowly been discovered by people to practice, the garden has also been gradually a ddd learning atmosphere and valuable practical experience to share. In fact, before I was also obsessed with ddd, why would be obsessed with it is not because it is so-called new technology, nor because of various speculation on it, but I think I found a way to liberate our business system development methodology.

DDD can be a good guide to develop reliable software systems, especially in today's business complex and changeable situation, using DDD can be very good with the business changes to constantly reconstruct the existing domain model, most importantly, I think DDD is a good implementation of agile values of software development methodology.

If you want to refactor and test the business code you write, there is no need for the code to be moved properly, without a good structure that allows you to store the code you extracted. Including now the most important TDD methodology in the Agile software Development methodology the structure of the more dependent code can allow refactoring, if your structure is very rigid, flattening is actually difficult to implement TDD, you will find your abstract concept shameless accommodated.

So I think that ddd is a good way to solve these problems, of course, if you have done it yourself before you are qualified to judge its merits and demerits, and is objective and impartial.

The implementation of DDD is a time-consuming and laborious project, with no traditional development method so simple and fast, and a new standard for the overall requirements of developers, so this article will introduce a good alternative to the DDD mode of the "active record Mode".

2. A brief introduction to the domain model mode, Activity recording mode

The domain model model is actually the domain-driven design, two is a meaning. Interested friends can learn more about domain-driven design, I think DDD is an essential design idea for an enterprise application developer, like design patterns, it also has a set of patterns to guide us in the design of the relevant business scenarios.

Domain model patterns, also called domain-driven design, do an equivalent object-oriented modeling of business models, without much consideration for the technical details of data storage, but not entirely about how to store it, and if someone tells you that you don't have to think about storage at all, it's wrong because you have to consider how this domain model ultimately lasts. Lest you create the domain model as a huge spider web. Saying that there is no need to consider how the domain model is persisted is that you only need to grasp the domain model creation, not to complete the persistence design details, but these two tasks are often considered each other.

Is it possible for a person who does not know how to store relational data to create a model that satisfies the programmer's good development?

The active record pattern is the closest mode to DDD, which takes a row from a table in the database as its own object field, and then wraps the data fields and business logic in an instance object around the business logic that expands on those fields.

The active record mode differs from the table module pattern in that the table module pattern is an object that corresponds to a table in a database, and the active record pattern is an object that corresponds to a row record, so called the active record mode.

The biggest benefit of this mode is that it can basically satisfy the business is not very complex scenario, I think the activity record mode in the current SOA-oriented architecture can be more suitable for enterprise business System development team. Using domain drivers is too complex to use and will face a rapidly changing business situation, so the activity logging mode can be considered for trial.

3. Simple examples and key points of activity recording mode

Let's look at a simple example to understand the development and key points of the activity logging pattern.

The active record mode uses the class in a way that is always the same as the table structure in the database, that is, the columns in the table are the fields of the class, and of course the auxiliary fields when processing the business logic, as far as possible, do not include extra fields, which can effectively guarantee the clean activity record.

namespace business.recordmodels.ordermodel{using System;     Using System.Collections.Generic;    <summary>//Order table fields.        </summary> public partial class OrderFields {//<summary>///Order ID.         </summary> public long OId {get; set;}        <summary>///Order name customer declare.         </summary> public string Oname {get; set;}        <summary>//Product IDs.         </summary> public list<long> PIds {get; set;}        <summary>//Order sum price.         </summary> public float price {get; set;}        <summary>//Order distribute status.         </summary> public int Distributestatus {get; set;}        <summary>//Order payment status.       </summary> public int Paymentstatus {get; set;}  <summary>//Order signer.         </summary> public string Signer {get; set;}        <summary>//Submit datetime.    </summary> public DateTime Submitdt {get; set;}  }}

Define a field class for the order activity record, or you can define the field directly in the order class, but generally I like to be independent because once the field is too much it looks really tired. If you want to define a field directly in the Order class, I recommend that you use a partial class to handle it, which is cleaner.

The public list<long> PIds {get; set;} Commodity ID collection fields are intentionally aggregated into the field class, because both business processing and data persistence require related business fields. (Activity logging mode does not require you to be a very rigid form of a record instance, as long as you use your own way to make the code structure look natural is very appropriate.) ）

Although you use the int type directly to describe the business field, you can use the other way to make the field not use the language type directly in the business process but the business concept.

namespace business.recordmodels.ordermodel{//<summary>//    Distribute status Const.    </summary> public    class Distributestatusconst    {public        const int nodistribute = 1;         public const int begindistribute = 2;         public const int Enddistribute = 3;    

The distribution status constant class, which defines the value of a clear business concept.

namespace business.recordmodels.ordermodel{//<summary>//    Payment status Const.    </summary> public    class Paymentstatusconst {//<summary>//        No payment.        </summary> public        const int nopayment = 1;         <summary>//        End payment.        </summary> public        const int endpayment = 1;    

The distribution status constant class, which defines the value of a clear business concept.

Creation of activity records I suggest that we use the factory to deal with, after all, the bread here contains a lot of business logic inside.

namespace business.recordmodels.ordermodel{using Common;    <summary>//Order class factory.        </summary> public class Orderfactory {///<summary>//Create a order instance. </summary>//<param name= "Fields" >order fiels instance.</param>//<returns& Gt;order instance.</returns> public static Order Createorder (OrderFields fields) {if (Fiel Ds. IsNull () | | Fields. Oname.isnullorempty () | | Fields. Pids.isnullorempty () | | Fields.             Price.islessthanorequal0 ()) return null; Fields.            Distributestatus = distributestatusconst.nodistribute;//no Distribute. Fields.             Paymentstatus = paymentstatusconst.nopayment;//no payment.        return new Order (fields); }    }}

Activity recording mode is not equal to no ddd so good, in fact, the business is relatively not very complex situation, the activity record mode is quite good, simple and fast, for some atomic types of field processing using constants is very good.

Here we use Distributestatusconst.nodistribute, paymentstatusconst.nopayment constant field to express the business concept, rather than to use the enumeration, experience tells me that sometimes enumeration is not a constant convenience.

The activity Record object contains the business logic that the record expresses, and the order will contain the business logic processing that the table expresses.

namespace business.recordmodels.ordermodel{using System; <summary>//Order table record///</summary> public partial class Order {//<su        mmary>//Order table columns.         </summary> private orderfields fields {get; set;}        <summary>//New A order instance only internal use. </summary>//<param name= "Fields" >order fields.</param> internal Order (OrderFields F        Ields) {this.fields = fields;        }//<summary>//Calculate order expiration time.        </summary>///<returns>DateTime</returns> public DateTime calculateexpirationtime ()            {//here can use strategy. if (This.fields.PaymentStatus = = paymentstatusconst.nopayment)//no payment logic {return THIS.F Ields.            Submitdt.adddays (1);        }    else if (this.fields.DistributeStatus = = distributestatusconst.nodistribute)//no payment Logic {            return This.fields.SubmitDt.AddDays (30);        } return This.fields.SubmitDt.AddDays (3);  }    }}

Here I have a simple method for calculating the current order expiry time (calculateexpirationtime), there are some business logic inside the method, and the business logic exists with the current instance.

By using the active recording mode, it is good to set up the fields effectively with the business method, which makes the business logic processing more organized and easy to test and reconstruct.

It is emphasized here that the activity record mode is the business layer and the data layer common mode, at that time we are talking about the business layer, that is, you can use the data layer in any way and active record mode integration, now more popular ORM, if you have performance requirements you can use manual processing, It is recommended to use the table entry mode to combine, because the data layer has no logic, if your data layer has related logic I will not appear on the last data source, but should be disposed of on the data adaptation layer, such as: Cache, fill the field and so on.

4. Summary

It is difficult to explain all of the problems in an article, and the activity logging mode must require a "unit of work" mode to reconcile the transactional between multiple "records" if it is used to read and write in a large, disconnected schema. But if you use the Activity logging mode on the query side, then most of the cases do not need transactional, of course, the query side I think the use of things script mode is more intuitive, because the business logic will not be much.

or that sentence, this article is only a sharing point of their own learning process and work process summary experience, for reference only. in fact, enterprise application architecture is a seemingly simple actually very complex direction, I hope with you to learn together progress, 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-use active record mode instead of domain model mode