Entityframework-driven design practices (6)

ArticleDirectory

• Model object lifecycle-factory

Model object lifecycle-factory

First, we should realize that an object has a lifecycle. This is applicable to both object-oriented languages and domain-driven design. In the domain-driven design, the model object lifecycle can be expressed briefly:

You can see that the object is created from scratch through the factory and is active after creation. At this time, you can participate in the business processing at the domain layer; objects are stored to achieve persistence (that is, we often say "save") and Reconstruction (that is, we often say "read "). Objects in the memory are destroyed by structure analysis, and objects in the persistent state are revoked through warehousing (that is, we often say "delete "). The entire state transition process is clear.

Now we have introduced two roles for managing the model object lifecycle: factory and warehouse. At the same time, it should be noted that the factory and warehouse operations are based on aggregate root, not just for entities. There will be a lot of content about warehousing, which will be described separately in the next section. This section describes how to implement a factory in the. NET Entity Framework.

The. net object framework automatically generated Entity Data Model source code file, we found that ,. net object framework adds a factory method for each object, which contains a series of parameters of the original data type and value type. For example, the customer entity in our case has the followingCode:

Hide row number Copy code ? Customer Factory

2. /// <Summary>

4. ///Create a new customer object.

6. /// </Summary>

8. /// <Param name = "ID">Initial Value of the ID property.</Param>

10. /// <Param name = "name">Initial Value of the Name property.</Param>

12. /// <Param name = "billingaddress">Initial Value of the billingaddress property.</Param>

14. /// <Param name = "deliveryaddress">Initial Value of the deliveryaddress property.</Param>

16. /// <Param name = "loginname">Initial Value of the loginname property.</Param>

18. /// <Param name = "loginpassword">Initial Value of the loginpassword property.</Param>

20. /// <Param name = "dayofbirth">Initial Value of the dayofbirth property.</Param>

22. Public staticCustomerCreatecustomer (Global: System.Int32ID,NameName,AddressBillingaddress,

24. AddressDeliveryaddress,Global: System.StringLoginname,

26. Global: System.StringLoginpassword,Global: System.DatetimeDayofbirth)

28. {

30. CustomerCustomer =NewCustomer();

32. Customer. ID = ID;

34. Customer. Name =Structuralobject. Verifycomplexobjectisnotnull (name,"Name");

36. Customer. billingaddress =Structuralobject. Verifycomplexobjectisnotnull (billingaddress,"Billingaddress");

38. Customer. deliveryaddress =Structuralobject. Verifycomplexobjectisnotnull (deliveryaddress,"Deliveryaddress");

40. Customer. loginname = loginname;

42. Customer. loginpassword = loginpassword;

44. Customer. dayofbirth = dayofbirth;

46. ReturnCustomer;

48. }

 

When creating a customer object, you can use the customer. createcustomer factory method. It seems that the. NET object framework is close to the idea of domain-driven design. The following several points need to be explained:

 

• when using this factory method to create a customer object, you must give the first parameter "Global: system. int32 ID "value assignment. In fact, this ID value is used in the persistence mechanism. when an object is created, this ID value should not be specified by developers. Therefore, it is unnecessary for developers to forcibly specify an id value here. In fact ,. every entity in the net object framework inherits from the entityobject class, and this class has an entitykey attribute, which is used as the object key, therefore, the ID value here must be maintained by the persistence mechanism. We can also see that the entity in the domain-driven design has two identifiers: one is based on the business architecture, and the other is based on the technical architecture. For example, in a sales order, we can see more identifiers like "so0029473858" on the interface, rather than an integer or GUID
• This factory method can create a customer object, assign values to each member attribute of the object, and jointly create value objects related to the object to aggregate members (such as the customer's creditcards) it is created and filled when used. In this way, object creation should be based on Aggregation and system performance can be improved. For example, the following standalone test is used to check whether the creditcards attribute of a customer object created using the factory is null (if it is null, it proves that the aggregate root does not reasonably maintain the integrity of the aggregation ):
  
• the. NET Entity Framework only provides a simple factory method for each entity. The concept of "Factory" has the following best practices in the field-driven design:
  • the factory can hide the details of object creation because object creation is not considered in the business field.
  • the factory is used to create the entire aggregation to maintain the domain meaning represented by the aggregation.
  • you can add the processing factory method in the aggregation root or use the factory class. That is to say, you can create a customerfactory class and define the createcustomer method in it. Whether the factory method or the factory type is selected depends on the needs
  • when you need to input parameters to the created object, you should minimize coupling. For example, you can use an abstract class or interface as the parameter type.

Here you will find that the factory and the warehouse seem to have this connection, that is, they can all create objects, but the difference is that the factory is an object created from nothing, warehousing is more inclined to "Rebuilding ". Warehousing is more complex than the factory because it needs to deal with the technical architecture of the persistence mechanism. In the following article, I will introduce a warehouse Implementation Method Based on. NET object framework that is not restricted by the object framework.

 

 

----- [The following is the comments and replies of original users ]-----

Re: domain-driven practices of the Entity Framework (6) [11:48:00 | by: xiaos (visitor)] It seems that the repository should focus on get and load, while the factory is create. The reply from the blog master is as follows: Yes, I also mentioned in this article: "The factory is an object created from nothing, while the Warehouse is more inclined to" Rebuilding "". Repository needs to deal with technical architecture, while factory does not.

Re: domain-driven practices of the Entity Framework (6) [21:34:00 | by: haojie77] I am also studying DDD recently. As you mentioned in this article, "from here, we can see that the entity in the domain-driven design has two identifiers: one is based on the business architecture, the other is based on technical architecture. "I have two questions. 1. in domain, the Order identifier should be a string such as "so0029473858. however, GUID is only used for database storage (or it must be used by EF). Isn't it the guid of an entity in a domain concept? I have seen other people's posts saying that do not treat identifiers as database primary keys. Can an entity have n (n> = 2) identifiers? 2. The relationship between identifiers and database primary keys should not be one-to-one, right? Identifiers are often mapped to the primary key of the database, but the identifiers are not necessarily the primary key of the database. do you understand this? I was just learning about DDD, so I am not very clear about some concepts. I hope to learn more about DDD from you. (8, 9, 10 ...), thank you! The following is the reply of the blog owner: yes, the primary key of the database must be distinguished from the entity key. The reason is simple: the former is the content of the technical architecture, while the latter is the business field. In a domain model, two objects with the same object key can be considered as the same object. Of course, you can use the business entity key as the primary key of the database. For example, you can use the sales order number "so0029473858" in the database as the primary key of salestable, in this case, you must generate this key value technically and assign it to the entity key before persisting the object. In other words, when the entity key is used as the primary key of the database, the mechanism for maintaining this key value is your system, not the database. This may have a certain impact on performance, which is also mentioned in the domain-driven design book. The typical case is the number sequence mechanism in Microsoft Dynamics ax. It is a serial number generation mechanism that can be expanded in depth. In dynamics ax, such as the sales order number is generated and maintained by this mechanism. "can an entity have n identifiers "? The answer is no. Only one. An identifier is used to uniquely identify an independent entity. One of the two values I mentioned above is at the technical architecture level. In a domain model, an entity can only have one identifier. I wonder if my answer above can help you. PS: there is no time to update recently, but I will try to update it as soon as possible.