Where does the “business logic layer” fit in to an MVC application?

Question

First, before anyone screams dupe, I had a hard time summarizing it in a simple title. Another title might have been \"What is the difference between a domain model and MVC

Answer 1

The MVC pattern and the Asp.net framework makes no distinction on what the Model should be.

MS's own examples include persistence classes in the model. Your question about membership being in the model. This depends. Are classes in your model owned by something? Is there a link between who logs in and what data is displayed? Is there filtering of data part of a permissions system that is editable? Is who last updated or edited an object part of your domain as in somebody else needs to see it or something for backend support?

The email example is also it depends. Are you familiar with domain eventing or eventing in particular? Do you have a separate service to send emails? Is the act of sending an email part of your domain or is it a application level concern outside of the scope of your system? Does the UI need to know if an email was sent successfully or not? Do emails that fail to send need retries? Does the content of the email sent need to be stored for support or customer service requirements?

These types of questions are overly broad and subjective but I'm answering so you and everybody who voted you up can understand this.

Your requirements/timelines/resources all bleed into your system's architecture. Even the revenue model can have an effect. You also have to consider the pattern you are shooting for. DDD is much different than persistence-as-model applications and all the slop in between are also valid for certain apps. Are you shooting for testing the app? All of this has an effect.