MVC应用程序架构的数据流

Question

Attempting to validate the approach for data flow in an MVC application that i am cleaning up and streamlining, (after a bit of refactoring) things currently looks like the diagram below (Data flow indicated by arrows). and some parts are written to access the the repository services jumping over layers. (Like an HTML helper directly accessing a repository service for lookup data)

Few Questions.

1. Is this a typical design and are there any pitfalls?
2. Is skipping layers for trivial things acceptable?
3. The flow of data is it architecturally sound?

Answer 1

1. This seems to be a common design. Unfortunately I don't have enough experience to point out pitfalls of the design, as the current project I am on is my first experience with this architecture.

2. If you say that repository services are being accessed in multiple layers, aren't you missing a few arrows? Ideally, you don't want to be accessing your repository from the controller (or a Razor helper) as that makes your code more tightly coupled and muddies your otherwise good separation of concerns. However, that isn't to say it is terrible to have some limited repository access in multiple modules. The best practice would be to move these repository calls into your business logic, and pass it on to the controller from there.

3. The ASP.NET project I'm currently on is using a very similar architecture and we are having success with it.

Answer 2

Seems already quite good.

Typically I have following layering:

• Presentation layer : contains MVC web site with models, controllers, views and view models.
• Services layer : contains services exposed to everything in presentation layer (in the form of WCF service or web API or even just a class library).
• Application layer : contains application logic, in my case these are command and query handlers that use underlying domain model and infrastructure services.
• Domain layer : domain entities and services, has no dependencies to other layers and contains domain logic.
• Infrastructure layer : contains infrastructural concerns, like data access, logging etc...

To minimize dependencies, I program against interfaces; of which the concrete implementation is injected by an IoC container. This means that every component is also very testable.

Your controllers of the presentation layer are thin, and use the services layer only (and infrastructure layer).

This is a very flexible approach, yet simple enough to work for most types of applications. Also, if you use entity framework, you might want to think about whether you actually need repositories and unit of work.