UI Design Patterns

Question

I have been reading about MVP, MVVM and have used asp.net MVC in couple of practice projects. These patterns are mostly referred to as UI patterns, which is bit confusing for me, since I used to think that only Views (in MVC) are the UI and the Model is data access layer + BLL. My question is if I use Entity Framework (edmx) as my Model, why would I need to have a separate layer for data access (DAL) and what would this data access layer actually do in this scenario.

Answer 1

MVC and the others are considered UI/presentation patterns because their primary mission is to accept requests from an outside source and display results. The M portion of those patterns generally refers to simple models that are used as DTOs (data transfer objects) that help populate the views (also known as view models).

Business logic, if it's more intense than just CRUD operations, is generally separated out from this. That allows different kinds of front-end apps (an MVC site here, an actual phone/tablet app there) to interact with the data in different ways.

In other words, MVC and the like are really just a skin on top of the business logic that actually does stuff.

You'll need to ask yourself if it makes sense to separate out your EF portion from the rest of your project. If you're doing more than just CRUD operations on your data, I'd say yes.

Answer 2

You don't explicitly need a separate DAL, since EF is your data access layer and model at the same time. If you us POCO's for your model, you need a layer to handle the persistence of these objects. So if you use NH as OR/M, then your model simply consists of POCO objects and NH is your DAL. Usually NH is hidden in a separate layer, but this isn't really necessary. If it comes to the GUI, the your entities aren't used directly for binding etc. The MVVM introduces the ViewModel for it, that functions as layer between the GUI and the Domain Model and provides all the data from the model that is needed by the GUI.

Answer 3

Actually both views and controllers deal with UI. Basically, everything except Model Layer, is for and about UI. And you must understand, that things like REST API also are just a different kind of user interface.

As for your research, i would recommend for you to take a harder look at Model2 MVC and HMVC as patterns. Former is the closest thing to classical MVC, that you can do for web. And the latter has very interesting use-cases and solves re-usability problems (and also has some potential in distributed systems).

Now for the main question.

You separate domain business logic (in domain object) from data access logic (in datamappers), because you gain following features:

• code decoupling, separation of concerns
• ability to unit-tests independently

Basically, this lets you have codebase, where addition of a specific change (like adding cache, or model level authorization checks) do not require you to rewrite whole codebase.

Also the storage mechanism itself becomes a lot more flexible. You can easily change where your data for a specific domain object is stored. For example, you can move user details and authentication to a noSQL database. This would not have ANY impact on how your business logic works. This becomes a critical issue, when you are working in larger teams or maintain old code, because it is very hard to grasp whole system and keep this knowledge up-to-date.

As for what the data access layer does: it takes domain objects (the things, that contain domain business logic) and either stores data from them or retrieves information into them for data source layer.

Also, i would recommend to research/watch:

• SOLID principles
• Unit testing (I would recommend to watch all the lecture from Clean Code Talks)

_{Disclaimer: my primary language is PHP, and only have experience with MVC-related patterns in the context of web (mostly with the Model2 variant of it, because of the obvious limitations of web itself), which has shaped my understanding of MVC structure.}