Say I have a person table in a database. Whenever a new person is added into the database, a pdf will be generated and emailed to someone.
Does this logic go into the model, so all the application does is pass in the data to insert the new person, and the model also handles the pdf and email?
Or does this logic go into the controller?
If this should go into the model, and I am using entity framework, how do I do this? Create a .cs class that wraps the .edmx model?
It is my understanding that you would not want to muck up the controller with that kind of logic. Things that belong in the controller would be defining models that are going to get passed to the view or turning validations on or off. There are several other view related things that the controller should control but that is just a couple. The general point that I am trying to make is that the controller is responsible for populating models by calling services or mocked repositories and then passing those models to the view.
To do what you are explaining I would add a service layer that sits above the data access layer (dal – where your EDMX and repositories sit). Inside that service layer is where I would call the methods or services to generate the pdf and send emails.
The repositories and data access layer should only be concerned with querying the database and retrieving records. That is regardless of what ORM or data access tool you use. the retrieved records are passed to the service layer where you can perform actions against the data (such as validations or sending out pdf’s) and then the presentation layer is returned whatever format of the records that it needs to display it in the view. The controller doesn’t perform any logical action against the retrieved data but instead just hands it off to the view.
If you would like some more details about the architecture layout that I have described then I would be happy to give you more insight into it.