So I have a MVC app and in another project I have a normal collection of classes which handle the Business and Data logic for the application. I also have some logic in the Model of the MVC project itself. This logic handles ViewModels and the like, things which could not have been done in the n-tier project as they relate to the MVC project itself and need to be in the same project.
My questions are:
- Should my model classes have knowledge of the n-tier business logic? Or should only the controller have this knowledge and send data back and forth between the n-tier application and the MVC model as needed?
- If it’s ok for my model to reference the n-tier application, then should my controller access n-tier via the model class?
Hope this makes sense, found it difficult to word correctly to get my point across.
Generally speaking here – Your model classes should not have business logic knowledge. They should have only the information required to display the view to the user (use DTOs as suggested by mxmissile).
Your business logic would either be in your controller, or (better) in a separate service layer called by your controller. Having methods on a model that, for instance, bypass the controller and make calls directly to the database is almost always a bad practice.
The idea here is to make the views as dumb as possible. You send them a model, they pull out the data they need, format it appropriately, and display it. This makes it much easier to create new views of the same data later if you decide you want to change the presentation.