The MVC cheerleaders and Scott "THE DOT" GU make a big deal out of separation of concerns like this is some great break through. This is nothing new or anything to get excited about we have been easily pulling this off in Visual FoxPro for years through N-TIER and so has rails through MVC.
Now some of you maybe thinking VFP wasn't a web-tool, actually it can be used for web development which is out side the scope of this blog post but I used the same VFP middle tier classes in classic asp applications and in desktop lan applications. But more importantly if you understand design patterns then you would realize, it should NOT matter what the UI is, who cares, if it is a webform, winform, a service or mobile device. It is Microsoft's inability to build a productive tool which is the only reason this is a concern.
If Soma and the boys at Microsoft would have followed an N-TIER thought process and included a "HEAVY DUTY" class browser and focused developers on building a code repository that could be used across any UI seamlessly with VS containing an open source code generation layer that handled all the plumbing code NOW that would have been a "GREAT" tool.
The part that frustrates me, yes even more than standing next to an Indian at a public defecation pool with a bad case of diarrhea, is how close FOXRPO was to accomplishing this feat. If they would have added a form base class of type webform it would have worked. I actually often thought of doing just that and have it churn out the HTML and CSS based on classes. Damn I should have Soma's job lol.
Instead Soma and Microsoft got off on this tangent of composite UI controls and never ending layers of bloat, combined with bastardized paradigms that require a vast amount of "more" work then legacy Visual FoxPro did to "separate concerns" which is highly concerning.
I believe MVC separation of concerns is based more upon a flaw/lack of understanding with regards to Webforms, competing with ruby and implementing a "new" but copied design pattern then really "FIXING" the design pattern problem which is deeply rooted in Visual Studio and .BLOAT.
I will get off my soapbox and further explore Visual Studio's MVC separation of concerns.
N-TIER patterns are one way developers could "truly" separate concerns, here is a quick refresher on how this works.
The UI Layer - Handles user input and sends and retrieves data to the business layer.
The Business Rules Layer - Validates information, performs processing and connects to the data access layer to send and retrieve information.
The Data Access Layer - Is responsible for connecting to the data source. In some cases this is a base class for the business rule class or can be a separate layer in the event we need the ability to use different back-end databases such as My Sql, FoxPro, Sql Server, Oracle etc...
The Database - This is merely My Sql, SQL Server, Oracle, Access, FoxPro etc...
N-TIER is linear: UI hits the middle tier and the middle tier hits the data tier.
With MVC the tiers are triangular, views hits the controller and model and the controller hits the model. Even thou it is a triangular pattern that still doesn't mean we should not be concerned with code reuse.
In Visual FoxPro given it had a "functioning class browser" it was very easy to assemble these layers and setup a class "tree" hierarchy. Developers only had to concern themselves with application code and there was a "true" separation of concerns. Fox developers weren't not concerned with writing plumbing code or dealing with framework syntax that is more bizarre then crossing an intersection at rush hour in India.
With Visual Studio the class browser is mainly a nice looking UI plumbing code template generator that functionally does absolutely nothing mentionable. The VS class browser is unable to visually subclass UI controls amongst other things, in short, it is just about as fast to build your Visual Studio classes by hand in notepad.
If you want a more in depth comparison here is a link regarding the UI layer and class browser with code samples. When I went back and reread that post it is amazing how consistent I am which is more then I can say for some cheerleaders.
Now that we have a basic understanding of how concerns can be separated and the difference between VFP'S class browser and Visual Studio's want-a-bee class browser implementation lets explore what happens in an MVC application.
In the UI Layer of MVC we end up with some nice HTML, if we are good little coders. Next we have to inject the data access, business rules and validation to make the html do something productive, unless of course we are Scott "THE DOT" Glue then making it do anything that may reveal the truth of how messy VS MVC is, well, lets just say is out side the scope of his specs.
In most "GOOD" applications when the user tabs out of a field we should give some feedback to let the user know if their input is not valid. This is where separation of concerns falls apart with Microsoft's MVC implementation. In MVC field level validation is pulled off by using Javascript, Jquery and alligator script syntax etc... bloating the hell out of our NICE html or we could use the the range attribute property of EF (which I discussed in a prior post). If you are sharp, you should immediately see we have already lost our separation of concerns and the code is "NO LONGER" dry.
Despite what the MVC'ERS are bragging about here is what is "really" happening in the controller code with most applications I looked at in the field and sample code written by cheerleaders. The controller becomes this massive bloat of spaghetti code combining data access, linq, business rules, authentication and data sets with varying degrees of duplicated code in the UI. Worse yet the code is further duplicated from controller to controller and also into the web services because developers are NOT using "true" OOP design patterns.
I found a brief video that helps explain this point a bit more, enjoy. :)
There are several reasons why I believe this happens:
Microsoft ignored the model layer in their paradigm making it difficult to work with and now they seem to be forcing EF as the model layer, good luck with that one. Some developers haven't worked in C++ or VFP therefore don't have a firm grasp of OOP programming concepts or design patterns and fail to setup a good class structure if they use any class libraries at all. They merely are following some false hope and Microsoft marketing efforts to make them believe because a controller layer is involved in their application they are following OOP design principles and therefore their concerns are separated.
Anyway lets look at some code shall we, that may help...
This was pulled right off the blog of a Visual Studio cheerleader to validate a login in MVC.
Here is a very real world scenario.
A programmer is working on a site and "googles", log in validation + MVC, they find this sample with some documentation and implements it. The blogger is an Indian MVP from Microsoft so he has to know what he is talking about right? - come on do you really think this doesn't happen? My good friend Soma was blogging about script junkie, trust me this shit happens all the time!
A few minutes later, cool, the site is working, users are getting in and some users are denied access. The developer is happier than a two-dicked billy goat and thinking wow those cheerleaders f'ing rock man!
A month later they receive a request to add in a web-service to this web app that requires a username and password before it can return some data. So the programmer cracks open VS/.BLOAT then armed with C# and a KB article works some magic and the web-service is working.
I think you can see where this is going, we have validation crap in the controller, the html and a web-service.
And folks I will say it again this unfortunately is "REAL WORLD" stuff. This is how quickly an application turns into bloat because a "true" design pattern was not implemented from the get-go.
Don't worry I get it, you been brainwashed into thinking webforms controls are bad due to viewstate and extra lines of code VS injects into the html along with losing control over the id's then there is also the postback issue etc... but isn't the real solution to fix webforms/VS? Isn't using the code behind to bind up a list view and act as a bridge between the middle tier and UI a "workable solution" to a bad situation when it comes to separating concerns? If the web-forms code behind is merely calling classes in a middle tier how is that not separating concerns?
Some closing thoughts.
Look there is nothing wrong with MVC as a pattern, the issue is Microsoft's tools are lagging behind the technology (debugging, intellisense, class browser etc) and what Microsoft's final MVC implementation will be like is anyones guess, if it even makes it to maturity. Companies have spent an enormous amount of time and money jumping on the MVC bandwagon early and now stuck supporting some really ugly code.
Many cheerleaders are hyping this technology simply because it is new and "cool" and that type of bullshit doesn't do anyone much good. Pick technologies because it serves a purpose to your development efforts not because it is cool or because "DOT GLUE" or some freaking cheerleader says so. Using MVC doesn't mean separation of concerns, you still need a well planned out class structure or you will just end up with spaghetti code in a new framework.
Webforms is a mature product that will be around for a while don't dismiss it on a whim, it could end up saving you a significant amount of development time.
That is enough for today.
Happy Coding!
.Mark
No comments:
Post a Comment