Pro ASP. net mvc 3 Framework study note 4

 

Topic: Applying Domain-Driven Development)

 

Domain Model is the "heart" of the MVC program. Everything else, including Controllers and Views, is only a way to interact with the Domain Model. ASP. net mvc does not limit the use of Domain Model technology, we can freely choose. net framework interaction technology, and there are many such choices. In addition, ASP. net mvc provides us with the basic architecture and conventions to help the Classes in the Domain Model communicate with Controllers and Views, as well as the relationship with MVC itself. They have three key functions:

A. Model Binding: it is a basic convention that automatically uses data submitted by HTML forms to organize Domain Objects.

B. Model metadata: Describes the meaning of Model Classes for. net. For example, it is to give a person an easy-to-understand expression of the attribute or some prompts when the attribute is displayed. Asp.net mvc can automatically identify and reasonably present Model Classes to Views.

C. Validation: rules that can be executed when the model is bound and can be applied as element data.

If you have the same understanding of Model Binding, you do not have to worry about it. Do not give up learning MVC, this is because the subsequent chapters of the book will be explained in detail. Now let's put the implementation of ASP. net mvc aside and simply think about Domain Modelling. Next we will use. net and SQL server to create a simple Domain model for the bidding program.

 

1. Create a simple domain model

The following is a class diagram of the auction program to be created

 

The above model contains a set of Members. Each Member has a Bids set, and each Bid corresponds to an Item. Each Item can have multiple Bids from different Members.

The key to implementing our own domain model as an independent component is the language and terminology we choose. This is not our programming language, but a general language for domain Modeling. This language is known to developers and professionals in the field. This is mainly for smooth communication between the two, which is crucial. When experts in the field do not understand some modeling concepts, we should reach a consensus on the terms used. This consensus is to create a common language and run through the modeling process in the entire field. This has many advantages.

 

1. First, developers tend to use programming languages, such as class names and databases. Business experts do not understand this, and they do not need to understand it. It is very dangerous for business experts to know some technical knowledge, because they will constantly filter their needs based on their understanding of the technology, this means that the demand will be changed frequently, so that developers do not know what the real requirements of business experts are. The method of creating a common language can help us avoid the need for over-generalization in an application. Programmers tend to create a practical business model rather than a specific business requirement.

 

2. the connection between a common language and a Domain model should not be superficial, but should be suggested to the Domain-Driven Design experts: any changes to the general language will lead to changes to the Model. If we do not synchronize modeling with the business field, we need to build an intermediate language for ing from Model to domain. In the long run, this approach will lead to a disaster. To this end, we will create a special human with two languages, and then they will start to filter the needs, which is based on their incomplete understanding of both languages, of course, such consequences can be imagined.

 

2. Aggregation and Simplification

The above figure provides a good starting point for modeling.

However, the Model shown above does not provide any useful help for implementing the Model using C # and SQL Server, and many problems may plague us:

1. If we load a Member into the memory, should we load its Bids and related Items into the memory?

2. If we do this, do we need to load the other bids of this Item into the memory, and load the Members of these Bids into the memory together?

3. Should I delete an object when we delete it? If so, what else?

4. If we choose to use document storage instead of relational databases for persistence, which object set should be presented to the same document?

We do not know how to answer all the above questions, and our domain model does not give us any answers.

The DDD method to answer these questions is to allocate Domain Objects to the group, which is called aggregates ).

 

The following shows how to aggregate the Domain Models in our bidding program:

 

 

Www.2cto.com

An aggregated entity group combines several domain objects (Together), and a root entity is used to identify the entire aggregation, it acts as a "boss" in verification and persistence operations. When data changes, I regard aggregation as a unit for overall handling. Therefore, we need to create an aggregation of meaningful relationships in the context of the domain model, create logical operations that are consistent with the business process. That is to say, we need to create aggregation through grouping objects, and these objects can be changed as a group.

 

An important DDD rule is that objects out of the scope of an aggregation instance can only be persistently referenced by reference to the root entity, rather than the objects referenced in the aggregation. This rule reinforces the concept of treating objects in aggregation as a unit. In this example, both Members and Items are the root of aggregation, while Bids can only be accessed in the context of the Item as the root entity for their aggregation. Bids can reference Members (root entity), but Members cannot apply Bids (not root entity)

 

One advantage of aggregation is that it simplifies the relationship between objects and Domain Models. This usually helps us to understand the nature of the domain that requires modeling. Essentially, the relationship between the domain model and the object of the aggregation constraint makes the relationship closer to the existing one in the real world. The following is expressed in C #, as shown below:

 

Public class Member {

Public string LoginName {get; set;} // The unique key

Public int ReputationPoints {get; set ;}

}

Public class Item {

Public int ItemID {get; private set;} // The unique key

Public string Title {get; set ;}

Public string Description {get; set ;}

Public DateTime AuctionEndDate {get; set ;}

Public IList <Bid> Bids {get; set ;}

}

Public class Bid {

Public Member {get; set ;}

Public DateTime DatePlaced {get; set ;}

Public decimal BidAmount {get; set ;}

}

 

From the code above, we can easily capture the nature of the unidirectional relationship between Bids and Members. Of course, we can also establish some other constraints. For example, Bids are immutable, which is also practical. Application aggregation can help us build more useful and accurate domain models, and help us use C # To implement them skillfully.

 

In general, aggregation adds structure and accuracy to a domain model. This also makes application verification easy (the root entity is responsible for verifying the state of all objects in the aggregation), which is obviously a persistent unit. Since the essence of aggregation is the atomic unit of the domain model, they can also be applied to the unit of Transaction Management and the unit of cascading deletion from the database.

 

On the other hand, aggregation is often artificially limited. The concept of Aggregates can be naturally obtained from document-based databases, but it is not a concept of sqlserver itself, nor is it a concept in most ORM tools. In order to implement them well, our team needs scientific and effective communication.

 

3. Defining Repositories)

In some cases, we need to add persistence to the domain model, which is usually done through relational, object-type, or document-type databases. Persistence is not part of our domain model. It is an independent focus, which means we cannot mix persistent code with the code that defines the domain model. To solve this problem, we usually define a repository (Repositories)

Respositories is based on the object rendering at the database (You may choose file storage, etc.) level. Domain Models indirectly store and query databases by calling the methods defined in Repositories, so that our Model can be implemented independently of persistence. This Convention defines a separate data model for each aggregate. In our bidding program, we can create two Repositories for Members and for Items respectively. Note that we do not need to create a Repository for Bids, because Bids will be part of the persistence of the Items party ). The two Repositories are defined as follows:

 

Public class MembersRepository {

Public void AddMember (Member member ){...}

Public Member FetchByLoginName (string loginName ){...}

Public void SubmitChanges (){...}

}

Public class ItemsRepository {

Public void AddItem (Item item ){...}

Public Item FetchByID (int itemID ){...}

Public IList <Item> ListItems (int pageSize, int pageIndex ){...}

Public void SubmitChanges (){...}

}

 

Note: Repositories only applies to Loading and Saving Data. They do not contain any other logic.

 

Today's notes are made here. I just learned MVC and took notes to consolidate and deepen my understanding. Of course, I am very happy to be able to help beginners who are just like me a little bit. There will certainly be something wrong with my notes. Please help me with your guidance. Thank you!

Wish the passing friends a smooth job!

 

Good night!

 

 

Author Gabriel Zhang