MVC Application Structure

Question

So I am new to MVC and have read about a couple dozen of similar questions on SO and some blogs. I can't understnd how to structure my application. Either I'm not getting it or people seem to have different opinions on how to do it. So here is my specific, simple example: login screen and account create screen.

From my understanding I should have the following:

view Simple in this case two views

model Two view models. Login has username and password. Register has username, password, email, etc. Only properties no methods.

controller Builds view model by calling service layer like CreateUser()

business/service Separate project. Has methods to interact with database and apply business logic. Called by controller which massages output into view model format. This project has its own models/classes not tied to a specific view. CreateUser() in this layer would call the stored procedure on the db

Is that the correct flow? And also when returning data from the business layer I shouldn't use the view models. So do I create another set of models on the business side that resemble the logical entities in the db?

Answer 1

This sounds reasonable. The point about separate models and view models is a general advice in order to avoid tight coupling between your service layer and your UI. It means that multiple applications can consume the services even if their UI screens are different. I do however think it in some cases makes sense to skip the view models if they become mirror images of the models. I only tend to create view models if they add some sort of value when it comes to preparing the data for the view (formatting etc).

However, some might claim that you should always create view models - even ones that mirror the model. I can understand that argument as well since it is related to avoiding coupling between the UI and the service which enables you the evolve the service without changes up the chain to the UI. You have to make a judgment call on how important that is for you since that comes at the cost of a layer that "ferries" values between identical objects.