I wanted to provide my opinion on the MVC pattern usage, to generate any discussion and/or guidance that might be gained from my study of this pattern.
For some time now I’ve been reading and listening to the pundits of the Model View Controller Pattern for ASP.NET; also known as WebMVC pattern. I’ve built some prototypes and used
the pattern via exercises to gain knowledge of this new pattern soon to be delivered in VS 4.0.
As this pattern is now becoming more fully defined and is soon to become a standard pattern supported in ASP.NET vs 4.0, I thought I would provide you with my opinion as to whether
we should or should not adopt this pattern in web application development here at GSOC.
My view is guided by what, if any benefits does it yield and what, if any downside is there.
On the positive side the pattern offers a clean separation of view, logic, and data tiers. There is no doubt that this is accomplished because that is the main objective of MVC.
However, the logic or controller components are still trapped in the web domain and are not re-usable outside of that domain. They depend on global.asax settings and run under iis http. Therefore, there is no re-usability of this component outside of the
web site… You could not for instance, make use of that logic in a winforms application or service.
Moreover, the ability to cleanly separate presentation, business logic, and data access is available today without the MVC pattern. Using WCF and multi-tiered programming – we have
the ability to provide the same separation and we have no less ability to share these components (especially via WCF) with non-web application such as services, win-forms, and even non-.Net platforms. In fact, with WCF we can globally share business and
data logic without restriction of MVC’s ties to iss /http: platform. Hence, I’m not sure the separation of model, view, controller duties, provided by MVC, buys us much here.
A down side issue for me, is that the view components – in the MVC Pattern – revert to the classic asp method of coding, where <%= for each ….. style coding is mixed into the html
web page. This is very hard for me to buy into.
The .net code behind / server code model is much cleaner and much more understandable that the classic asp approach to coding and I would not want to see the mixing again of html
and c# or vb code as the way of the future.
Microsoft itself has stated that MVC is an optional pattern, use it if you like it or don’t if you don’t feel comfortable with it. The capabilities of MVC are available without MVC
and for me, the choice is that we should not pursue this coding pattern. There is very little, if anything to gain, and the negative use of html/mixed with application code is less than attractive to me. The more valuable approach to XXX, in my opinion,
is to pursue and take advantage of multi-tiered programming, WCF, and the code behind asp.net techniques.
Because the separation of the model, view, controller components doesn’t provide out of web usage – it falls short in my opinion of the goal of writing application and data logic
once and re-using in anywhere you need it. To me, WCF is a better answer to this need and it does not fall short. For instance, the .net prototype of the new GDP that I wrote and is now on hold, is using multi-tiered programming and WCF. Its business and
data tiers have already been proven in testing to allow both windows forms, service, and web apps to access these tiers and access complex objects from that pattern. This, is the better choice in my opinion.
I would not recommend the use of MVC pattern, unless there is some circumstance – unforeseen to me at this time – where it would be mandated and would provide some otherwise unattainable
goal.
As the poet John Dryden observed in 1681, "Fools are more hard to conquer than persuade."
I'm not on the MVC bandwagon yet, but I do appreciate it. Reasons:
1. It was coz of MVC that jquery has 1st party support. Everyone doing MVC was using jquery...and the rest is history.
2. Test automation. MVC is way more testable than web forms. This is a major bonus. You don't need a web server to test, you don't need to track user interaction as in web tests, etc.
3. You can use MVC with WCF services just as in webforms. It's by no means a replacement for WCF. WCF is simply a Wonderful and Charming Framework ;)
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
To the OP, your post COULD be interesting if something did not exist, but it does. This something are "Web Standards"
I challenge you making a xhtml compliant, wcag-aaa compliant, accessible and usable web site using webforms without going crazy.
I challenge you using standard unobtrousive JS without going crazy.
I challenge you having a full webforms site work fine with JS disabled. You simply can't if you use some asp:controls because they depend on JS. And since a true web site/application MUST be 100% usable with no JS or CSS support, a great part of the asp:controls
is senseless.
I challenge you BEING a professional web developer using webforms. Webforms is a paradigm to allow winforms programmers to approach the web without knowing it. That's why it's something for amateurs.
Real web developers KNOW WHAT THEY ARE DOING, and therefore use tools that allow them to follow the rules. Those tools are Ruby on Rails, Microsoft Asp.NET MVC, MonoRail and some others, but NOT webforms.
So much for your "unforseen reasons". You are not a web developer, no wonder you can't understand. People pretending to be web developers without even knowing the basics, are a real insult to OUR profession.
Sorry if I sound rude but I am sick of hearing total amateurs sentencing on a profession that they don't even know. Go to Hulk Hogan and teach him how to wrestle, I'd be amused to see his reaction.
However, the logic or controller components are still trapped in the web domain and are not re-usable outside of that domain. They depend on global.asax settings and run under iis http. Therefore, there is no re-usability
of this component outside of the web site… You could not for instance, make use of that logic in a winforms application or service.
I would argue that you're not trying to reuse your controllers. Your controllers should be simple, and to the point. Your model/domain should be thick. If you have complicated controllers that need to be reused, then you probably have something wrong.
A down side issue for me, is that the view components – in the MVC Pattern – revert to the classic asp method of coding, where <%= for each ….. style coding is mixed into the html web page. This is very hard for me to buy
into.
There, IMO, is nothing wrong with that style of coding. The main issue with ASP was the mixing of business logic with presentation logic. You should only have presentation logic within your view. Even then, you can eliminate a lot of the looping and structure
controls with helper methods.
The .net code behind / server code model is much cleaner and much more understandable that the classic asp approach to coding
I completely disagree. The code behind model is much more complicated. Events, controls, life cycle. Lots of stuff. Have you tried testing those pages? The code-behind model is too complicated.
and I would not want to see the mixing again of html and c# or vb code as the way of the future.
As a developer, you need to learn not to mix logic into your views. Being a better developer is the way of the future. If there is complicated logic in your view, then you have a serious concern outside of the framework.
There is very little, if anything to gain, and the negative use of html/mixed with application code is less than attractive to me. The more valuable approach to XXX, in my opinion, is to pursue and take advantage of multi-tiered
programming, WCF, and the code behind asp.net techniques.
Again, you should not have application code in your view. Sure, you could do it. But you know how much application code and presentation code
could be mixed up in the code-behind model. A ton. In fact, I've rarely been to a company that didn't have an application coded in such a way.
Futher, testability is one thing you gain right away.
I can certainly see the benefits of MVC and many other tools but to say that webforms is only for amateurs is utter nonsense and really only serves to discredit you. While I agree that in a perfect world all websites would be usable with or without JS
or CSS not all websites live in the public facing world. I have worked on many internal websites developed using webforms as well using the MVC pattern. I would argue that real developers know their requirements and know their audience and can determine
the best tool for the job that meets the requirements and can get the job done in the least amount of time. Some places that's MVC, some places it's webforms, etc. Where I work, webforms does the job quite well.
Thanks, you helped make the point I may not have made that well. I too think MVC is a great model. I've had higher expections though, in that I do think the controller logic should be re-usable from any platform. I don't say that my expection was the
only way to think about it, but if I'm going to trade in Winforms for simply the ability to force clean seperation - I already have three tiered applications, using WCF and a business layer that is re-usable from windows services, and othe applications - as
it communicates with wcf. Am I incorrect in my thinking that the controller contains this business logic? If it does, then it is not re-usable... I'd be happy to hear someone explain where I'm wrong. I'm not an MVC expert, but I'm trying to see, in my environment,
where it gives me value that I don't have.
Thanks for taking time to give me this feed back. I have benefitted from you detailed reply and I will continue to listen and evalute with the benefit of your comments.
Am I incorrect in my thinking that the controller contains this business logic? If it does, then it is not re-usable... I'd be happy to hear someone explain where I'm wrong. I'm not an MVC expert, but I'm trying to see, in my environment, where it gives me
value that I don't have.
No, the controller should not contain the business logic. A controller should not make business decisions. The controllers are only there to link your domain/model/business logic to your view. It helps inform the view of your model. It's basically the bridge
that connects the two.
jparlato
Thanks for taking time to give me this feed back. I have benefitted from you detailed reply and I will continue to listen and evalute with the benefit of your comments.
jparlato
Member
5 Points
12 Posts
I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 09:10 AM|LINK
I wanted to provide my opinion on the MVC pattern usage, to generate any discussion and/or guidance that might be gained from my study of this pattern.
For some time now I’ve been reading and listening to the pundits of the Model View Controller Pattern for ASP.NET; also known as WebMVC pattern. I’ve built some prototypes and used the pattern via exercises to gain knowledge of this new pattern soon to be delivered in VS 4.0.
As this pattern is now becoming more fully defined and is soon to become a standard pattern supported in ASP.NET vs 4.0, I thought I would provide you with my opinion as to whether we should or should not adopt this pattern in web application development here at GSOC.
My view is guided by what, if any benefits does it yield and what, if any downside is there.
On the positive side the pattern offers a clean separation of view, logic, and data tiers. There is no doubt that this is accomplished because that is the main objective of MVC. However, the logic or controller components are still trapped in the web domain and are not re-usable outside of that domain. They depend on global.asax settings and run under iis http. Therefore, there is no re-usability of this component outside of the web site… You could not for instance, make use of that logic in a winforms application or service.
Moreover, the ability to cleanly separate presentation, business logic, and data access is available today without the MVC pattern. Using WCF and multi-tiered programming – we have the ability to provide the same separation and we have no less ability to share these components (especially via WCF) with non-web application such as services, win-forms, and even non-.Net platforms. In fact, with WCF we can globally share business and data logic without restriction of MVC’s ties to iss /http: platform. Hence, I’m not sure the separation of model, view, controller duties, provided by MVC, buys us much here.
A down side issue for me, is that the view components – in the MVC Pattern – revert to the classic asp method of coding, where <%= for each ….. style coding is mixed into the html web page. This is very hard for me to buy into.
The .net code behind / server code model is much cleaner and much more understandable that the classic asp approach to coding and I would not want to see the mixing again of html and c# or vb code as the way of the future.
Microsoft itself has stated that MVC is an optional pattern, use it if you like it or don’t if you don’t feel comfortable with it. The capabilities of MVC are available without MVC and for me, the choice is that we should not pursue this coding pattern. There is very little, if anything to gain, and the negative use of html/mixed with application code is less than attractive to me. The more valuable approach to XXX, in my opinion, is to pursue and take advantage of multi-tiered programming, WCF, and the code behind asp.net techniques.
Because the separation of the model, view, controller components doesn’t provide out of web usage – it falls short in my opinion of the goal of writing application and data logic once and re-using in anywhere you need it. To me, WCF is a better answer to this need and it does not fall short. For instance, the .net prototype of the new GDP that I wrote and is now on hold, is using multi-tiered programming and WCF. Its business and data tiers have already been proven in testing to allow both windows forms, service, and web apps to access these tiers and access complex objects from that pattern. This, is the better choice in my opinion.
I would not recommend the use of MVC pattern, unless there is some circumstance – unforeseen to me at this time – where it would be mandated and would provide some otherwise unattainable goal.
As the poet John Dryden observed in 1681, "Fools are more hard to conquer than persuade."MCP
SOFTWARE ARCHITECT
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 12:07 PM|LINK
1. It was coz of MVC that jquery has 1st party support. Everyone doing MVC was using jquery...and the rest is history.
2. Test automation. MVC is way more testable than web forms. This is a major bonus. You don't need a web server to test, you don't need to track user interaction as in web tests, etc.
3. You can use MVC with WCF services just as in webforms. It's by no means a replacement for WCF. WCF is simply a Wonderful and Charming Framework ;)
blog: www.heartysoft.com
twitter: @ashic
Sgro
Participant
782 Points
352 Posts
Re: I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 02:50 PM|LINK
To the OP, your post COULD be interesting if something did not exist, but it does. This something are "Web Standards"
I challenge you making a xhtml compliant, wcag-aaa compliant, accessible and usable web site using webforms without going crazy.
I challenge you using standard unobtrousive JS without going crazy.
I challenge you having a full webforms site work fine with JS disabled. You simply can't if you use some asp:controls because they depend on JS. And since a true web site/application MUST be 100% usable with no JS or CSS support, a great part of the asp:controls is senseless.
I challenge you BEING a professional web developer using webforms. Webforms is a paradigm to allow winforms programmers to approach the web without knowing it. That's why it's something for amateurs.
Real web developers KNOW WHAT THEY ARE DOING, and therefore use tools that allow them to follow the rules. Those tools are Ruby on Rails, Microsoft Asp.NET MVC, MonoRail and some others, but NOT webforms.
So much for your "unforseen reasons". You are not a web developer, no wonder you can't understand. People pretending to be web developers without even knowing the basics, are a real insult to OUR profession.
Sorry if I sound rude but I am sick of hearing total amateurs sentencing on a profession that they don't even know. Go to Hulk Hogan and teach him how to wrestle, I'd be amused to see his reaction.
Web Developer
IWA Member
ShaneBauer
Member
462 Points
102 Posts
Re: I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 03:24 PM|LINK
However, the logic or controller components are still trapped in the web domain and are not re-usable outside of that domain. They depend on global.asax settings and run under iis http. Therefore, there is no re-usability of this component outside of the web site… You could not for instance, make use of that logic in a winforms application or service.
I would argue that you're not trying to reuse your controllers. Your controllers should be simple, and to the point. Your model/domain should be thick. If you have complicated controllers that need to be reused, then you probably have something wrong.
A down side issue for me, is that the view components – in the MVC Pattern – revert to the classic asp method of coding, where <%= for each ….. style coding is mixed into the html web page. This is very hard for me to buy into.
There, IMO, is nothing wrong with that style of coding. The main issue with ASP was the mixing of business logic with presentation logic. You should only have presentation logic within your view. Even then, you can eliminate a lot of the looping and structure controls with helper methods.
The .net code behind / server code model is much cleaner and much more understandable that the classic asp approach to coding
I completely disagree. The code behind model is much more complicated. Events, controls, life cycle. Lots of stuff. Have you tried testing those pages? The code-behind model is too complicated.
and I would not want to see the mixing again of html and c# or vb code as the way of the future.
As a developer, you need to learn not to mix logic into your views. Being a better developer is the way of the future. If there is complicated logic in your view, then you have a serious concern outside of the framework.
There is very little, if anything to gain, and the negative use of html/mixed with application code is less than attractive to me. The more valuable approach to XXX, in my opinion, is to pursue and take advantage of multi-tiered programming, WCF, and the code behind asp.net techniques.
Again, you should not have application code in your view. Sure, you could do it. But you know how much application code and presentation code could be mixed up in the code-behind model. A ton. In fact, I've rarely been to a company that didn't have an application coded in such a way.
Futher, testability is one thing you gain right away.
MCP - ASP.NET
dsa1971
Member
142 Points
144 Posts
Re: I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 03:56 PM|LINK
I can certainly see the benefits of MVC and many other tools but to say that webforms is only for amateurs is utter nonsense and really only serves to discredit you. While I agree that in a perfect world all websites would be usable with or without JS or CSS not all websites live in the public facing world. I have worked on many internal websites developed using webforms as well using the MVC pattern. I would argue that real developers know their requirements and know their audience and can determine the best tool for the job that meets the requirements and can get the job done in the least amount of time. Some places that's MVC, some places it's webforms, etc. Where I work, webforms does the job quite well.
jparlato
Member
5 Points
12 Posts
Re: I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 06:16 PM|LINK
You do sound rude, but thats ok... I appreciate your taking the time to respond. Have great day.
MCP
SOFTWARE ARCHITECT
jparlato
Member
5 Points
12 Posts
Re: I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 06:23 PM|LINK
Thanks, you helped make the point I may not have made that well. I too think MVC is a great model. I've had higher expections though, in that I do think the controller logic should be re-usable from any platform. I don't say that my expection was the only way to think about it, but if I'm going to trade in Winforms for simply the ability to force clean seperation - I already have three tiered applications, using WCF and a business layer that is re-usable from windows services, and othe applications - as it communicates with wcf. Am I incorrect in my thinking that the controller contains this business logic? If it does, then it is not re-usable... I'd be happy to hear someone explain where I'm wrong. I'm not an MVC expert, but I'm trying to see, in my environment, where it gives me value that I don't have.
MCP
SOFTWARE ARCHITECT
jparlato
Member
5 Points
12 Posts
Re: I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 06:25 PM|LINK
Thanks for taking time to give me this feed back. I have benefitted from you detailed reply and I will continue to listen and evalute with the benefit of your comments.
MCP
SOFTWARE ARCHITECT
ShaneBauer
Member
462 Points
102 Posts
Re: I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 06:33 PM|LINK
No, the controller should not contain the business logic. A controller should not make business decisions. The controllers are only there to link your domain/model/business logic to your view. It helps inform the view of your model. It's basically the bridge that connects the two.
You're welcome. Glad I could help.
MCP - ASP.NET
brianjlowry
Member
59 Points
46 Posts
Re: I DON'T RECOMMEND MVC - HERE IS WHY?
Nov 11, 2008 09:43 PM|LINK
ViewState is embarrassing. That's all that needs to be said.