. Net: Some Thoughts on data models, domain models, and view Models

Document directory

• Sample Code
• Sample Code

Background

Data Models, domain models, and view models are three types of "models". Some architectures use one type to represent these three roles, such as the traditional three-tier architecture. There are also some architectures that use two types to represent these three roles, such as the domain-driven architecture combined with Orm. In rare cases, three types of roles are used to represent these three roles. I have done this only in some fields, such as the workflow engine.

Today, I only want to talk about one topic: Is it necessary to introduce an independent type for the view model? Or is it easier to express the domain model and view model with one type? Introduce some words:

• Solution A: express the role of the domain model and view model in one type, which is also called the Open Domain to view (open domain to view ).
• Solution B: introduce an independent type for the view model, also known as using a data transmission object (DTO ).

Solution

Because the domain model and view model are a type, the domain model will be rebuilt from the UI, because the domain model will be rebuilt from the UI, And the UI Layer cannot be trusted, therefore, you must verify the domain model (including the isvalid () method), and many methods in the domain are to repair the illegal state of the domain model, such: recalculate the total order amount, encrypt Unencrypted Password attributes, and so on.

Sample Code

 1     internal sealed class TestGridCommandHandler : ApplicationService, 2         ICommandHandler<CreateTestGrid>, 3         ICommandHandler<UpdateTestGrid>, 4         ICommandHandler<DeleteTestGrid> 5     { 6         public void Handle(CreateTestGrid command) 7         { 8             var testGridService = this.Service<TestGridService>(); 9 10             testGridService.Create(command.TestGridInfo);11             command.Id = command.TestGridInfo.Id;12         }13 14         public void Handle(UpdateTestGrid command)15         {16             var testGridService = this.Service<TestGridService>();17 18             testGridService.Update(command.TestGridInfo);19         }20 21         public void Handle(DeleteTestGrid command)22         {23             this.Service<TestGridService>().Delete(command.Id);24         }25     }

Note that the second method indicates that command. testgridinfo is the domain model. After the client is rebuilt, it directly calls applicationservice for update. Update is responsible for repairing the model status, performing verification, and processing optimistic concurrency.

Solution B

Because the domain model and view model are different types, the domain model will not be rebuilt from the UI. Because the UI is only a view model, a domain model should be loaded from the database, then merge the view model into the domain model. The merge here does not refer to the use of a merge tool such as automapper, it is a reasonable merging process (reflection cannot bypass the logic encapsulated by the domain model). In this merging process, the domain model is always in a valid State (or it can be invalid, many people keep the isvalid () method ).

Sample Code

 1     internal sealed class TestOrderCommandHandler : ApplicationService, 2         ICommandHandler<CreateTestOrder>, 3         ICommandHandler<UpdateTestOrder>, 4         ICommandHandler<DeleteTestOrder> 5     { 6         public void Handle(CreateTestOrder command) 7         { 8             var testOrderService = this.Service<TestOrderService>(); 9 10             var testOrder = command.CreateTestOrder();11 12             testOrderService.Create(testOrder);13             command.Id = testOrder.Id;14         }15 16         public void Handle(UpdateTestOrder command)17         {18             var testOrderService = this.Service<TestOrderService>();19 20             var testOrder = testOrderService.Repository.Load(command.Id);21             testOrder.CheckOptimisticKey(command.TestOrderInfo.OptimisticKey);22             23             command.UpdateTestOrder(testOrder);24             testOrderService.Update(testOrder);25         }26 27         public void Handle(DeleteTestOrder command)28         {29             this.Service<TestOrderService>().Delete(command.Id);30         }31     }

Pay attention to the second method. Here we first use repository to return a domain model from the database, execute the optimistic lock check, use the view model to modify the domain model (not a simple reflection), and then call applicationservice for update.

Remarks

If you look at the code, you may think that solution a is relatively simple, and solution B is a bit of a fart. I used solution a before, and the development efficiency is indeed high, however, it is quite uncomfortable to deal with complicated logic.

I am very confident to make good use of any solution, because a senior person tells me that paying attention to code details is better than paying attention to these architecture problems.

In combination with the four-color prototype, I think we can do this: Use the solution for PPT and DES, and use the B solution for MI.