DTO outdate mapping to database in C# - Domain Driven Design

c# dapper domain-driven-design entity-framework


I'm creating a project structure using C# and DDD architecture. I'm having trouble mapping outdated DTOs to domain models and persisting outdated data in databases.

The following situation

My desktop has 2 distributed clients that are obtaining data for the student with ID number 1.

  1. Clients 1 and 2 get a DTO from the server with the following information for the student with ID=1: Student:

    • ID = 1
    • Name in full: John;
    • Telephone: 01234;
  2. The Client 1 receiving the DTO, allowing the save operation, and Change this student's phone number to: 56789

  3. Client 2 receiving the DTO and Change this student's full name to Peter., and allowing the save operation to occur, leading to The new database has been maintained Full name is Peter; previous area code: 01234 (Un-expected behavior)

When a saving action is performed, the client returns the changed DTO to the server and the mapping to the domain model (Primary factor). The DTO retains the previous value (Phone: 01234) and maps it to the domain model.

Please provide me some advice on how to avoid this problem, such as a pattern or technology. The fact that numerous people may simultaneously modify the same application model makes this issue crucial.

Thank you a lot.

7/21/2017 10:40:38 AM

Popular Answer

A concurrency issue is what it is known as. There are several ways to approach it. Concurrency management capabilities are integrated into RDMS products like SQL Server and Oracle, for example, which might be useful (see the documentation provided by your database vendor). Prior to incorporating your chosen programming method, study and use them. You'll need to test what works best for your apps and how your users behave since I've seen the following done in some of the applications I supported, each with their own issues.

  • A field to hold the record's version may be added, for example (timestamp). Check to see whether the database version of the record matches the version that was saved by the user. You may also include tests to compare previous values with current values and new values in order to enhance integrity. If everything seems OK, save; if not, "reject" and notify the user.
  • The addition of fields like lock flags (user ID + time stamp) is another option. The lock flags are changed when a user wants to modify a record (along with the user's ID and the current time). The stored user ID "wins" edit mode in the user interface, while all other users are given read-only mode. The lock flags are removed when the editing user saves (or cancels) from the UI, making the record available for another edit request. Users are aware of who has locked a record and since when, which is advantageous. Cons: You could provide options to "expire" locks or allow users to "grab/steal" locks.
  • Finally, the solution may be put into practice, with people organized into groups to work on pre-assigned sets or ranges of data (or on a defined timetable) without duplication. Simple yet effective! Although it depends on user behavior, it might serve as a temporary fix while you build the concurrency management functionality for your program. The design and execution of this technique wind up becoming the users' SOP in the majority of the applications I supported, with the actual programmatic concurrency solution acting as an extra "safety check," or JIC.

There are other more approaches, each of which has drawbacks of its own. They range from being basic to advanced. OCC, event sourcing, and messaging are a few examples of named-patterns. Whatever the case, it is assumed that at least one request will be granted "first come, first served," with all subsequent requests responding in kind.

Hope this is useful!

7/21/2017 6:14:19 PM

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow