Apr 01
Why I hate MVC…
Personally, I’m a big fan on design patterns, so don’t judge by the title. The thing is that you can easily step on to the other side…when you’ve got a new project and you’re thinking right away which pattern should you use. I don’t see this as the correct coding attitude.
For the mvc in short :
The MVC(model-view-controller) paradigm is a way of breaking an application, or more commonly, just a piece of an application’s interface, into three parts: the model, the view, and the controller.
- Model
- The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items).
- Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
- View
- Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.
- Controller
- Processes and responds to events, typically user actions, and may invoke changes on the model.
You might want to look into this link if you want to know more about mvc.
In as3 there are many different MVC implementation already made and some of these that step up: Cairngorm and PureMVC. The reason why I don’t like to choose using mvc in my projects is that it takes the beauty away from coding. It is important to keep in mind that there are many different interpretations of how to implement the MVC pattern. But no matter if you choose creating your own or use one of the above, in MVC you will always be walking this line:
This architectural pattern will always guide you that way. Cairgorm for example (being the one that I’ve used in as3), not only that it guides you on a straight line it also fixes many problems before you encounter them. Thus with no problems will come no experience and especially no fun. This will easily transform you from a programmer into a programming user. And yes, I know that using mvc has some great benefits also, the most important ones being:
1. Lower complexity
2. Interface Flexibility
But there are many-many ways to get there…and you can think your “way” there.
April 1st, 2008 at 5:19 am
Im not a big fan of the number of files and amount of code necessary to use such a framework.
The way we tend to do things is prety simple. Lets say you have Product mainteance.
1. MXML file with the UI product.mxml
1. AS file with the base code product.as
1. CFM file with the Database interactions product.cfm
It’s prety simple. Both the AS and CFM extend base classes which provide core functionality.
Cairngorm is often a good example of making simple things complex for no other reason than best practice. Take this for example.
http://www.asfusion.com/assets/content/exampleFiles/flex/helloworld_cairngorm/srcview/index.html
April 1st, 2008 at 10:36 am
It’s definitely the case that MVC frameworks can take some of the thinking out of architecture, but this then allows you to work more efficiently in a team coding environment (because you all know the pattern), and also to spend more time on making it work and look beautiful and more usable, which can only be a good thing.
For more junior coders, it’s a great introduction into how you can structure robust and scaleable code, even if it is slightly bloated.
It’s all in how you interpret the framework really.
April 1st, 2008 at 2:46 pm
Even forgetting the massive team coding advantages already mentioned, is it smart to have to think through the same problems over and over? Most coders I’ve ever known have all collated a library of widgets, players, UI components, preloaders and other bits and pieces even before MVC was used in ActionScript. Using design patterns like MVC simply makes these components more flexible.
April 2nd, 2008 at 1:54 am
Indeed, I’m aware that MVC helps you in team work and you are most right.
Don’t get me wrong I wouldn’t advise anybody to re-invent the wheel here. And I’m aiming for MVC pattern only, not design patterns in general. @Dave MVC gives you a base structure for those component and I don’t see how this makes your components more flexible. All in one, I’m not saying to re-think the hole world here but when designing your application, MVC ain’t the only option and certainly it’s not always the best one.
April 4th, 2008 at 1:01 pm
OK, what about a clock widget? The Model emits the time and the Controller accepts a mouse click event that scrolls between a number of views, say digital and analogue. You could then reskin the clock any way you wished using only the hour, minute and second variables as inputs. Although it takes three classes instead of one to generate, if you needed to change the input time in the Model, to add to or enhance the user interaction, or to change the view, it becomes much simpler when it’s neatly separated.
Scalability: In another project, you could easily add some more buttons and change the Model to emit relative time (eg: to create a stopwatch). Or in another, you could create three world clock times in your View that are in sync simply by adding two simple lines of code.
To each his own, I guess. I think using MVC becomes self-fulfilling after a while. After a year of using it solidly in almost every major project, I’ve found it harder to go back to prototyping in the Flash IDE the way I used to.
April 4th, 2008 at 5:33 pm
Yes, this is actually “2. Interface Flexibility” mentioned above, which can be achieved in various ways. But, doesn’t this make all your projects that use that clock, MVC-dependent/oriented ? What if you would like to use that clock in a 100% non-MVC project ? Is the result of this really a clock “widget” ?
In any case, MVC is indeed a solid ground, but for me it takes away the fun and I’m fun-dependent.: )
April 16th, 2008 at 5:28 am
Although not MVC, at my work we build versions of an application using ASP.NET following an MVP pattern. I can’t stand it! Relatively simple tasks become monstrously convoluted. I remember one of my first tasks here was to show a table on 7 forms. I did it in codebehind first - it took 25 lines of code in each of the 7 files - simple, readable, easy for anyone else to understand, and best of all kept in the page (I know that’s just blaspheme for some!). Then I rewrote it in the MVP pattern that we use here. Gawd, 5 days later it was finished, 25 new files were created (interfaces, presenters, views, nhibernate mapping files etc.) and 10 existing files had to be edited. So now, we had the same functionality as before, yet the code is strewn throughout 6 projects and 35 files, it’s hard to navigate between them all (ie. much more unreadable), the solution is much more complex than it needs to be - and for very little gain. There are much simpler, manageable ways to seperate code than MVP. I can’t stand it….
April 24th, 2008 at 12:06 am
Another ASP.NET example we just finished in MVP. This website has:
- 11 web pages. To be conservative I’ll count user controls as pages as well (most plug into a wizard page) so that bumps the count up to 21 actual web pages.
- 8 solutions
- 50 projects/layers
- 852 supporting *.cs files (interfaces, views, business objects, DOA objects) not counting the designer.cs or aspx.cs code-behind files
- 56 Nhibernate mapping files
So that’s roughly 40 supporting *.cs files per web page for a fairly simple website. Frankly that’s just dumb. And whenever requirements change (let’s face it, they do) the architect/lead developer spends such a long time trying to work out whether the existing bloat can accomodate the marginal changes without breaking too many things.
There are alternative design patterns to MVP that are faster to write, more flexible to change, more maintainable, more readable/comprehensible, and which abstract code and seperate concerns to a reasonable level.
I really hope the old school Java programmers stuck thinking in this pattern retire and stop propagating this stupid architectural pattern.
May 2nd, 2008 at 11:50 am
Well the raw MVC is a long and old story. Nowadays it’s more a way of thinking about separation of concerns than a good hands on approach. But if you liked Cairngorm then you’ll love PureMVC. I bet you’ll feel that it does right some of the things you felt Cairngorm did wrong.
You really don’t want to do big service based team apps without using some kind of MVC. It might not be “correct coding attitude” but it’s a perfectly good code architecting foundation.
May 12th, 2008 at 9:51 pm
Applying patterns is less fun in deed but it also gets you quicker through a dull project. You have the requirements you know how to solve the problems so you can finish it and spend more time on R&D and challenge yourself with something a lot more interesting or get out and have a beer with friends.