Data from Database Using MVP-VM Design Pattern

Question

In my quest to understand MVP-VM design pattern in preparation for a new project which will be using DevExpress, I am unable to find an example with a database example.

Viewing DevExpress, I am unable to locate an example with this design pattern.

So, my question is this, does anyone who has experience of this design pattern, if you have experience of this with DevExpress even better, can give me an example of database connection, mapping data from a database (query/table) to model, and saving data to the database?

I appreciate this may sound rather an elementary question, but I do not know with this pattern what is the best practice for taking data from the view to persist to a database, and vice versa. Therefore, I do not wish to go off and doing incorrect.

Thanks

Answer 1

Classic architectures define the following parts:

DAL (Data Access Layer) : Deals with db operations, contains no business logic. BLL (Business Logic Layer) : Deals with business logic and constraints, but no database operations. PL (Presentation Layer) : Deals with presentation and user interaction.

MVP/MVVM deals with PL only. The big question is, what exactly is the M(odel) in this patterns. One example is using Entity Framework or DevExpress XPO to map objects to the database. But what are this objects? Are they the VMs? Are they the Model(s)? Or are they just simple Dtos of the Dal? If you look at the previous definitions, the last one will be the most matching one. But that means you have to map this dtos to you model objects (where the logic resides) and to you vms (where the databinding happens) or first to your model and in a second step from there to your vms? What about the filtering/sorting/paging capabilities of the datagrid, that only works if you give it direct access to you dal?

In my opinion true separation of the three aspects could only be achieved with CQRS or similiar architectures. At least I don't know of others. But this is only for extreme complex applications with lot of business logic and comes with much overhead and trade offs.

So, for your app, you have to decide which barriers you will break to suite your needs and to avoid needless complexity for your project. A simple CRUD application could use Entity Framework/XPO and use the objects directly as VMs for databinding. You have no bll at all. If it grows more complex you perhaps go a little bit in the direction of cqrs. You define views and use EF/XPO and their objects directly for databinding, but for complex operations you create a bll (domain)model with objects (that are loaded with EF/XPO either) that execute theese operations (needing to reload you vms afterwards). And if it is even more complex, you could go the complete way to CQRS perhaps with event sourcing and perhaps modeling with DDD.