. Net – tracks changes in complex object graphs

I started thinking about tracking changes in complex object graphs in disconnected applications I've found several solutions, but I want to know if there are best practices or what solutions to use, and why? I gave the same question to MSDN forum, but I only received one answer I want to learn more from the experience of other developers

This problem is related to Net, so I prefer the answer to the implementation details Net world, but I think it is the same on other platforms

The theoretical problems in my case are defined in the multi-layer architecture (not necessarily n layers at present), as follows:

>Repository layer that uses ORM to handle persistence (ORM tools are not important at present, but most likely Entity Framework 4.0 or NHibernate). > A collection of pure classes representing domain objects (persistent ignorance = poco equivalent to POJO in the Java World) These classes persist in the repository and are returned as query results. > Use the domain service set of the domain entity. > Define the facade layer from portal to business logic Internally, it uses repositories, domain services, and domain objects Domain objects are not exposed - each facade method uses a set of specialized data transfer objects for parameters and return values The responsibility of each facade method is to convert domain entities into DTOs and vice versa. > Modern web applications using elevation layers and DTOs – I call them disconnected applications Generally speaking, the design can be changed in the future, so the facade layer will be wrapped by the web service layer, and the web application will consume the service = > transition to layer 3 (network, business logic, database)

Now assume that one of the domain objects is an order with order details (lines) and related orders When the client requests an order, it can modify the order, add, delete or modify any order details, and add or delete relevant orders All these changes are done through the data in the web browser – JavaScript and Ajax Therefore, when the client presses the Save button, all changes will be submitted separately The question is how to deal with these changes? Repositories and ORM tools need to know which entities and relationships are modified, inserted or deleted I ended up with two "best" solutions:

>Store the initial state of the dto in the hidden field (worse, the session) When a request to save changes is received, a new dto is created based on the received data, and a second dto is created based on the persistent data Merge the two and track changes Merge the dto into the appearance layer and use the received information about the changes to set up the entity diagram correctly This requires some manual change tracking in the domain object so that the change information can be set up from scratch and passed to the repository later – which is something I'm not happy about. > Do not track dto changes When the modified data is received in the facade layer, the modified entity is created and the actual state is loaded from the repository (usually the additional query of the database - which is not satisfactory to me) – the two entities are merged and the changes of the entity agent provided by the ORM tool are automatically tracked (entity framework 4.0 and NHibernate allow this) Concurrent processing requires special attention because the actual state is not necessarily the initial state

How did you like it? What would you recommend?

I know that some of these challenges can be avoided by using caching at some application layers, but this is something I don't want to use right now

I am even more interested in this topic For example, suppose that the application enters a 3 - tier architecture and the client (web application) will not be in the Net = written in dto class and cannot be reused Tracking changes in dto will be more difficult because it will require other development teams to properly implement the tracking mechanism in their development tools

I believe these problems must be solved in many applications. Please share your experience

Solution

All this is about responsibility

(I don't know if this is your future answer - let me know, if not, I can update it)

Therefore, we have multiple levels in the system - each level is responsible for different tasks: data access, UI, business logic, etc When we build a system in this way, we (including) try to make future changes. Each component is responsible for one task - so it can focus on one task and do well Over time, the modification of the system has become easier and changed

When considering dto, A similar idea needs to be considered – "how to track changes? For example, here is how I deal with it: BL is responsible for managing rules and logic; given the statelessness of the network (which is where I do most of my work), I just don't track the state of an object and explicitly view changes. If the user is returning data (to save / update) , I will pass all the content to them without caring about the changed content

On the one hand, this seems inefficient, but the amount of data is not large, which is not a problem; On the other hand, fewer "moving parts" are less likely to go wrong because the process is simpler

How do I send back information

>I use dto (or maybe poco will be more accurate); When I exchange data between BL and DAL (through interfaces / DI), the data is exchanged as dto (or a collection of them) Specifically, I use a single instance structure and a collection of these structures into multiple. > Dto is defined in a common class with few dependencies. > I deliberately try to limit the number of DTOs created for specific objects (such as "order") – but at the same time, if there is a good reason, I will create a new object Usually I will have a "fat" dto, which contains most / all of the data available for this object. I may also have a more compact design for collections (lists, etc.) In both cases, these DTOs simply return "read" information You must remain responsible – when BL requests data, it usually does not write back the data at the same time; Therefore, the fact that dto is "read-only" is more in line with clean interface and architecture than business rules. > I always define separate DTOs for inserts and updates, even if they share exactly the same fields The worst that can happen is to repeat some trival code - instead of having dependencies and multiple reuse cases to solve it

Finally – don't confuse how DAL and UI work; Just because they store data in a specific way doesn't mean it's the only way

The most important thing is to specify meaningful interfaces between layers

Managing change is BL's job; Let the UI work in the way that best suits your users and let BL know how to deal with this problem. DAL (through your Di's clean interface) just tells you