OK, I've been thinking about this some more, and I'm still not clear on a few points, one of which may be what Bruce meant (didn't realise when I replied before)...
1) What is the inherent advantage of having logic in the model as opposed to the controller? Either way, you are presumably dealing with logic that needs to be in the MVC layer as a whole, as opposed to logic that should live in the BLL. Wherever you put
it, you still have to test it. The only difference I can see is that the controller already has a small amount of logic in it, in that it decides which view to send back. That is often closely tied with the MVC layer logic anyway, so it seems sensible to keep
the two together.
2) If you have data access code in the model, then that presumably means you need to create a custom class for every model, as that class is going to have to talk to the BLL. That sounds like a lot of extra work to me. If you have the communication with
the BLL coming from the controller, then the model could be something as simple as IEnumerable<Customer> for a list, or something like <Customer> for a single entity view. That way, the models are simply entities, or collections of entities, and don't require
a separate class.
3) Given that the view has access to the model, then adding the data access code to the model effectively means that the view can talk to the BLL, which I think is the point Bruce was making. If not, then this is another reason not to do it this way.
Please understand, I'm not arguing, or saying anyone is wrong, I'm asking these questions as I'm genuinely not clear why putting data access code in the model is a good idea. It looks to me like it would be better to do all this stuff in the controller,
and have the model as a dumb property bag. However, I want to know the best way to structure my MVC projects.
Thanks to all who have replied. Any further comments would be gratefully received.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/
Think of the BLL (could be just a library in your project where you isolate the domain model, data access and validation rules) as something that you can reuse. Maybe you decide to add a web service in front of it or reuse it in a windows application. You
will want the validation and dataaccess to be present othwerwise is just rewriting code.
Then in the MVC project the controller will talk with a repository to get an Employee from the store (could be a database, xml file or in-memory) then the controller will map (manually or automatically) the Employee domain model to an EmployeeViewModel (that
perhaps has only 3 of the 10 properties in the Employee view model) and give it to the view for display.
Again when you edit/add a new employee you will map between the view model and the domain model and have a repository update the store. Of course you need to duplicate some validation logic in the view (not all of it just basic stuff...the domain model will
also do its validation which can be more complex than just checking string length) but if you want to stay out of future problems I don't see other way
Please click 'Mark as Answer' if my reply has assisted you
I'm not sure if we are talking about the same setup. I usually have the UI layer (in this case, the MVC project) talk to a BLL, and the BLL talks to the repository. Unless I misunderstood what you wrote, it sounds like your UI layer is talking to both the
BLL and repository.
Either way, you mentioned having the controller do the work, not the model. Does that mean you disagree with the other posters here, as they seemed to be suggesting the model should be doing the work.
Thanks again.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/
Firstly, there is no such thing as a silly question. Many people must share this exact question - and surely if one has the question, another is bound to have the answer.
The following site, is a detailed explaination of where business logic should go when using MVC – the controller or the model.
Either way, you mentioned having the controller do the work, not the model. Does that mean you disagree with the other posters here, as they seemed to be suggesting the model should be doing the work.
I think me and bruce have the same basic idea..so I don't disagree with all the other posters :).
I am for a dumb model/view model (only data holders) and close to dumb controller (just get the data, map the data and call the correct view). I prefer to use other classes/services to validate, and talk to the store (whatever that is) - but this is a matter
of preference and there is no right/just one solution for all cases. You'll need to try one way or several ways of doing things and then adapt to your application complexity as needed.
Please click 'Mark as Answer' if my reply has assisted you
Thanks for that link. It fitted with the way I previously thought of doing it. I think I might have middued the waters in this discussion by referring to logic in the controller or model, implying I meant more than just what was needed to drive the UI layer.
That link clarified why some of the posts here sounded like they were suggesting something else!
To be clear, I have as much code of any description in the layer below the UI layer (usually a service layer of some sort), mainly because this enables the service layer to be used by other UI layers, and because it's much easier to test a service layer.
The logic I was referring to was mainly to do with the UI layer talking to that service layer, say to grab the data it needed, and push modifed or new data into the service layer. That was the stuff I was trying to discuss.
Thanks again, I think between all of these posts, I'm happy with the way I'm doing it, but can see that there are other (equally valid) ways as well.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/
Thanks for the clarification. As you can see from my reply to april_123456, I think
I was confusing the discussion! The way you and Bruce described it is basically the way I do it now, and will probably continue that way, unless I come across a situation where there is a good reason to do otherwise.
Thanks to everyone for a very helpful discussion.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/
I dont think MVC is a layer as such - its a software design pattern.
Validation logic can be generated FROM a model - eg: as an attribute [Required], which will be created in the View. These are all opinions. No one can tell you how to do things. They can only make suggestions supported by reason.
A popular design is to put all of the data methods in a BLL class THAT ONLY deals with data. ie: The Repository class. Why?
1. Decoupling
2. DRY
3. Single Responsibility
There are a few more but these are the important one for me.
(Please select 'Mark as Answer' if my response has helped you.)
I dont think MVC is a layer as such - its a software design pattern.
What I meant was that the part of the application that uses MVC was the layer that deals with the user interaction. As I understand it, MVC is a design pattern that is applied to a UI layer, which is why I referred to it like that. Same goes for MVP and
MVVM.
calibur
Validation logic can be generated FROM a model - eg: as an attribute [Required], which will be created in the View. These are all opinions. No one can tell you how to do things. They can only make suggestions supported by reason.
Yup, but it's good to gather opinions, as I want to see what the options are, so I can work out what is the best practice in any specific situation.
calibur
A popular design is to put all of the data methods in a BLL class THAT ONLY deals with data. ie: The Repository class. Why?
1. Decoupling
2. DRY
3. Single Responsibility
There are a few more but these are the important one for me.
As I mentioned in a previous post, my data methods are all accessed via the BLL. The UI layer (which may be a MVC web site, or an MVVM WPF application or whatever) calls BLL methods, and the BLL calls down to the repository. There are often other layers
in between, but that's the basic structure. That achieves all the aims you mentioned.
Thanks for the reply.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/
MrYossu
Member
134 Points
144 Posts
Re: Where does the logic go, in the controller or the model?
Jan 01, 2013 01:33 PM|LINK
OK, I've been thinking about this some more, and I'm still not clear on a few points, one of which may be what Bruce meant (didn't realise when I replied before)...
1) What is the inherent advantage of having logic in the model as opposed to the controller? Either way, you are presumably dealing with logic that needs to be in the MVC layer as a whole, as opposed to logic that should live in the BLL. Wherever you put it, you still have to test it. The only difference I can see is that the controller already has a small amount of logic in it, in that it decides which view to send back. That is often closely tied with the MVC layer logic anyway, so it seems sensible to keep the two together.
2) If you have data access code in the model, then that presumably means you need to create a custom class for every model, as that class is going to have to talk to the BLL. That sounds like a lot of extra work to me. If you have the communication with the BLL coming from the controller, then the model could be something as simple as IEnumerable<Customer> for a list, or something like <Customer> for a single entity view. That way, the models are simply entities, or collections of entities, and don't require a separate class.
3) Given that the view has access to the model, then adding the data access code to the model effectively means that the view can talk to the BLL, which I think is the point Bruce was making. If not, then this is another reason not to do it this way.
Please understand, I'm not arguing, or saying anyone is wrong, I'm asking these questions as I'm genuinely not clear why putting data access code in the model is a good idea. It looks to me like it would be better to do all this stuff in the controller, and have the model as a dumb property bag. However, I want to know the best way to structure my MVC projects.
Thanks to all who have replied. Any further comments would be gratefully received.
raduenuca
All-Star
24675 Points
4250 Posts
Re: Where does the logic go, in the controller or the model?
Jan 01, 2013 01:50 PM|LINK
Think of the BLL (could be just a library in your project where you isolate the domain model, data access and validation rules) as something that you can reuse. Maybe you decide to add a web service in front of it or reuse it in a windows application. You will want the validation and dataaccess to be present othwerwise is just rewriting code.
Then in the MVC project the controller will talk with a repository to get an Employee from the store (could be a database, xml file or in-memory) then the controller will map (manually or automatically) the Employee domain model to an EmployeeViewModel (that perhaps has only 3 of the 10 properties in the Employee view model) and give it to the view for display.
Again when you edit/add a new employee you will map between the view model and the domain model and have a repository update the store. Of course you need to duplicate some validation logic in the view (not all of it just basic stuff...the domain model will also do its validation which can be more complex than just checking string length) but if you want to stay out of future problems I don't see other way
Radu Enuca | Blog
0ramramram0
Member
305 Points
73 Posts
Re: Where does the logic go, in the controller or the model?
Jan 01, 2013 02:01 PM|LINK
Simple of the mvc ways
Any design's=css,Razor
Asign Property's =Model
Logic code's=Controller
DataBase call code's =Repository
Thank you
MrYossu
Member
134 Points
144 Posts
Re: Where does the logic go, in the controller or the model?
Jan 03, 2013 09:52 PM|LINK
Hi Radu, thanks for the reply.
I'm not sure if we are talking about the same setup. I usually have the UI layer (in this case, the MVC project) talk to a BLL, and the BLL talks to the repository. Unless I misunderstood what you wrote, it sounds like your UI layer is talking to both the BLL and repository.
Either way, you mentioned having the controller do the work, not the model. Does that mean you disagree with the other posters here, as they seemed to be suggesting the model should be doing the work.
Thanks again.
april_123456
Participant
775 Points
246 Posts
Re: Where does the logic go, in the controller or the model?
Jan 04, 2013 02:27 AM|LINK
Hello Mr. Yosso,
Firstly, there is no such thing as a silly question. Many people must share this exact question - and surely if one has the question, another is bound to have the answer.
The following site, is a detailed explaination of where business logic should go when using MVC – the controller or the model.
http://ianfnelson.com/archives/2010/11/03/mvc-where-to-put-business-logic/
Best of Luck!
With Kind Regards,
raduenuca
All-Star
24675 Points
4250 Posts
Re: Where does the logic go, in the controller or the model?
Jan 04, 2013 08:33 AM|LINK
I think me and bruce have the same basic idea..so I don't disagree with all the other posters :).
I am for a dumb model/view model (only data holders) and close to dumb controller (just get the data, map the data and call the correct view). I prefer to use other classes/services to validate, and talk to the store (whatever that is) - but this is a matter of preference and there is no right/just one solution for all cases. You'll need to try one way or several ways of doing things and then adapt to your application complexity as needed.
Radu Enuca | Blog
MrYossu
Member
134 Points
144 Posts
Re: Where does the logic go, in the controller or the model?
Jan 06, 2013 01:31 PM|LINK
Thanks for that link. It fitted with the way I previously thought of doing it. I think I might have middued the waters in this discussion by referring to logic in the controller or model, implying I meant more than just what was needed to drive the UI layer. That link clarified why some of the posts here sounded like they were suggesting something else!
To be clear, I have as much code of any description in the layer below the UI layer (usually a service layer of some sort), mainly because this enables the service layer to be used by other UI layers, and because it's much easier to test a service layer.
The logic I was referring to was mainly to do with the UI layer talking to that service layer, say to grab the data it needed, and push modifed or new data into the service layer. That was the stuff I was trying to discuss.
Thanks again, I think between all of these posts, I'm happy with the way I'm doing it, but can see that there are other (equally valid) ways as well.
MrYossu
Member
134 Points
144 Posts
Re: Where does the logic go, in the controller or the model?
Jan 06, 2013 01:34 PM|LINK
Hi Radu,
Thanks for the clarification. As you can see from my reply to april_123456, I think I was confusing the discussion! The way you and Bruce described it is basically the way I do it now, and will probably continue that way, unless I come across a situation where there is a good reason to do otherwise.
Thanks to everyone for a very helpful discussion.
calibur
Member
300 Points
124 Posts
Re: Where does the logic go, in the controller or the model?
Jan 07, 2013 09:35 AM|LINK
I dont think MVC is a layer as such - its a software design pattern.
Validation logic can be generated FROM a model - eg: as an attribute [Required], which will be created in the View. These are all opinions. No one can tell you how to do things. They can only make suggestions supported by reason.
A popular design is to put all of the data methods in a BLL class THAT ONLY deals with data. ie: The Repository class. Why?
1. Decoupling
2. DRY
3. Single Responsibility
There are a few more but these are the important one for me.
MrYossu
Member
134 Points
144 Posts
Re: Where does the logic go, in the controller or the model?
Jan 07, 2013 01:46 PM|LINK
What I meant was that the part of the application that uses MVC was the layer that deals with the user interaction. As I understand it, MVC is a design pattern that is applied to a UI layer, which is why I referred to it like that. Same goes for MVP and MVVM.
Yup, but it's good to gather opinions, as I want to see what the options are, so I can work out what is the best practice in any specific situation.
As I mentioned in a previous post, my data methods are all accessed via the BLL. The UI layer (which may be a MVC web site, or an MVVM WPF application or whatever) calls BLL methods, and the BLL calls down to the repository. There are often other layers in between, but that's the basic structure. That achieves all the aims you mentioned.
Thanks for the reply.