Comments on: How to explain MVC to a business and convince them it’s something they need http://c6s.co.uk/webdev/128 Web Application Development and Technology Wed, 08 Sep 2010 23:55:55 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: admin http://c6s.co.uk/webdev/128/comment-page-1#comment-9859 admin Wed, 12 May 2010 20:19:28 +0000 http://c6s.co.uk/?p=128#comment-9859 Hi John, thanks for posting that question. You're right in your assumptions that controllers shouldn't contain 'core' business logic. In theory you should always be looking to have Skinny controllers and Fat Models. However as controllers can have sequences/calls to models in the form of actions, you could interpret this as 'Business Logic' to a certain degree. The business logic could be seen to be the throughput from the controllers to models and back to controllers again. This is why I tried emphasising 'Core' business logic within the model to try and separate it a little. If you weren't to consider business logic as starting at the controller and take it literally then the theory would suggest business logic only sits within the model. Maybe it would have been better if I had said 'application logic' within the controller and 'business logic' within the model to make things clearer. Hi John, thanks for posting that question. You’re right in your assumptions that controllers shouldn’t contain ‘core’ business logic. In theory you should always be looking to have Skinny controllers and Fat Models. However as controllers can have sequences/calls to models in the form of actions, you could interpret this as ‘Business Logic’ to a certain degree. The business logic could be seen to be the throughput from the controllers to models and back to controllers again. This is why I tried emphasising ‘Core’ business logic within the model to try and separate it a little. If you weren’t to consider business logic as starting at the controller and take it literally then the theory would suggest business logic only sits within the model. Maybe it would have been better if I had said ‘application logic’ within the controller and ‘business logic’ within the model to make things clearer.

]]> By: John http://c6s.co.uk/webdev/128/comment-page-1#comment-9850 John Wed, 12 May 2010 12:24:11 +0000 http://c6s.co.uk/?p=128#comment-9850 Do controllers have business logic? I think this is about style of design, but controllers are supposed to only redirect views? Do controllers have business logic? I think this is about style of design, but controllers are supposed to only redirect views?

]]> By: Craig_Strong http://c6s.co.uk/webdev/128/comment-page-1#comment-1769 Craig_Strong Sat, 04 Jul 2009 09:24:56 +0000 http://c6s.co.uk/?p=128#comment-1769 Hi Leon, Thanks for the feedback. You raised some interesting points there most of which I agree. I think however there is a bit of confusion with probably the way I indicated explaining to the business. When I described the above, I don't mean the business literally in terms of persons far away from technology. This could like say alienate the business and break down communication. What I meant by business is more on the lines of business representatives such as business analysts and project managers, or persons that have more of an invested interest with the development section. These are the people declaring timescales and can take part of the blame in the event of failure, so often ask questions starting with why? If they are asking why something cannot be re-used or why can't we separate some of the current logic, this is where an explanation might be from a very high level. These maybe the same people that will need to allocate development time to create long terms plans for the business and are aware of costs and other such factors. However like you state MVC is not the definitive answer this is just an example of structure. Through lack of understanding or poor implementation, MVC could easily cause problems just like any other structural proposal. It's more of a theory based solution to consider creating maintainable systems as opposed to the answer to all problems if that makes sense? Again thanks for the reply, that has certainly added some value to this post. Hi Leon, Thanks for the feedback. You raised some interesting points there most of which I agree. I think however there is a bit of confusion with probably the way I indicated explaining to the business. When I described the above, I don’t mean the business literally in terms of persons far away from technology. This could like say alienate the business and break down communication. What I meant by business is more on the lines of business representatives such as business analysts and project managers, or persons that have more of an invested interest with the development section. These are the people declaring timescales and can take part of the blame in the event of failure, so often ask questions starting with why? If they are asking why something cannot be re-used or why can’t we separate some of the current logic, this is where an explanation might be from a very high level. These maybe the same people that will need to allocate development time to create long terms plans for the business and are aware of costs and other such factors.

However like you state MVC is not the definitive answer this is just an example of structure. Through lack of understanding or poor implementation, MVC could easily cause problems just like any other structural proposal. It’s more of a theory based solution to consider creating maintainable systems as opposed to the answer to all problems if that makes sense?

Again thanks for the reply, that has certainly added some value to this post.

]]> By: Leon http://c6s.co.uk/webdev/128/comment-page-1#comment-1768 Leon Sat, 04 Jul 2009 00:03:22 +0000 http://c6s.co.uk/?p=128#comment-1768 I disagree that any of this is necessary for three key reasons. 1) It's not a business decision unless you're selling source code. It's an implementation decision. I have never once had a non-technical business come up to me or my team and ask for a feature or fix, and then followed it up by saying "oh, and make sure you use **this** IoC container and use the Visitor pattern to parse our data files" as I say, those conversations just don't happen. Thank god. Can you imagine? 2) MVC alone is not a magic bullet that fixes broken software any more than Ruby on Rails is by its own virtue. What you want to build is better quality, more reliable and maintainable software. Now MVC alone doesn't give you that. Good architects, good project managers and good programmers do. MVC is one of many ways that can be achieved. But don't forget it's equally possible to build shockingly risible MVC systems too. Enter the architects and PMs. 3) If it's new to the team they will still have to learn the new technologies or techniques, or you will have to employ new people who do have these skills. This is doubling your notional cost to the business. Oh, and there's a possible 4) You are in danger of alienating the business by trying to explain esoteric software engineering concepts to them. They don't care. They want an IT department that **listens** and then **helps**. By forcing non-technical people to try to understand this you're potentially driving a political wedge between you and the business that will result in them never taking you seriously. Seriously, I wouldn't even mention it to them. Rather than this endeavour of trying to explain a software architecture methodology to people who just want easier and better ways to do *their* jobs, you'd be better off concentrating on getting requirements *from* the business, rather than giving irrelevant ones to it. I expect if the system is that bad, the business is well aware it needs addressing and they'll be receptive to any suggestion to tackle it. Especially one that the business feels like its in control of. I disagree that any of this is necessary for three key reasons.

1) It’s not a business decision unless you’re selling source code. It’s an implementation decision. I have never once had a non-technical business come up to me or my team and ask for a feature or fix, and then followed it up by saying “oh, and make sure you use **this** IoC container and use the Visitor pattern to parse our data files”

as I say, those conversations just don’t happen. Thank god. Can you imagine?

2) MVC alone is not a magic bullet that fixes broken software any more than Ruby on Rails is by its own virtue. What you want to build is better quality, more reliable and maintainable software. Now MVC alone doesn’t give you that. Good architects, good project managers and good programmers do. MVC is one of many ways that can be achieved. But don’t forget it’s equally possible to build shockingly risible MVC systems too. Enter the architects and PMs.

3) If it’s new to the team they will still have to learn the new technologies or techniques, or you will have to employ new people who do have these skills. This is doubling your notional cost to the business.

Oh, and there’s a possible 4) You are in danger of alienating the business by trying to explain esoteric software engineering concepts to them. They don’t care. They want an IT department that **listens** and then **helps**. By forcing non-technical people to try to understand this you’re potentially driving a political wedge between you and the business that will result in them never taking you seriously.

Seriously, I wouldn’t even mention it to them. Rather than this endeavour of trying to explain a software architecture methodology to people who just want easier and better ways to do *their* jobs, you’d be better off concentrating on getting requirements *from* the business, rather than giving irrelevant ones to it. I expect if the system is that bad, the business is well aware it needs addressing and they’ll be receptive to any suggestion to tackle it. Especially one that the business feels like its in control of.

]]> By: Anon Coder http://c6s.co.uk/webdev/128/comment-page-1#comment-1654 Anon Coder Sun, 28 Jun 2009 22:21:53 +0000 http://c6s.co.uk/?p=128#comment-1654 Great article! Really explained MVC well. The examples you mentioned put things right in perspective for me. I came across this at just the right time in my decision making. Thanks Great article! Really explained MVC well. The examples you mentioned put things right in perspective for me. I came across this at just the right time in my decision making.

Thanks

]]>