I have an MVC a开发者_如何学Gopplication which has the following architecture...
UI Project (MVC) Controllers (C) - instantiates view models ViewModels (M) - primary vehicle for feeding data to views Views
Business Layer
Returns data from Repository layer and returns entity/model objectsEntity/Model Layer (Domain Entity Layer)
Repository Layer ( Data Layer) Data access and returns entity/model objects to business layer
So, with the above architecture what interacts with the business layer? (viewmodels or controllers).
Without trying to sort through your terminology, I'll say that in java (and I think you'll see how this generally applies) the following structure is usually used:
Controllers are mapped to urls, and validate parameters. They delegate business logic to service classes. The service classes return models, which the controller passes to the view for rendering.
The service classes have dependency on the dao/repository layer, which does some kind of db lookup to get model objects and applies some business logic to it.
So back to your example, it's the controllers that interact with the business layer. The idea is to keep business logic out of the controller AND out of the dao layers.
Your controller is responsible to get the data, construct the viewmodel using that data and pass that Viewmodel to the view. To do that, you can inject the needed service into your controller, which talks to your service layer or business layer if you don't have a service layer.
In fact, to get data, you don't need your business layer or domain objects. You could create a query service that returns the data as needed by your views, which makes it easy to get data without the overhead of a domain model, which you don't need for querying (command query separation).
精彩评论