MVC Pattern in AS3
Just some random thoughts this morning, following a discussion with a colleague at work.
Perhaps it gets overused, and sometimes abused, but I find the MVC pattern a rather useful way of dividing up code. By using the pattern, I formalize what I would otherwise try to do anyway: separate my data from the graphical display, and make it easy to switch different views for the same data. And although with MVC you should be able to set up your data model so the actual data can take several forms, XML is so easy to parse with e4x that it’s really not worth the effort to create a separate class to act as a parser. So now I think I will call the data “model” the XML format itself. This does mean, however, that if data is actually stored in some other way, say in the database, a serializer will need to be created to generate this data model. This way the View in MVC can just parse the data format directly. The Controller’s role is usually limited to locating the xml file and instantiating the View, passing it the xml.
Or I could just wing it…
Hi there, good post! I totally agree on your comment about abuse/over-use of MVC. I think that force-fitting an application into the MVC pattern ( or any pattern for that matter ) as a default solution is the first mistake a lot of engineers make. I’ve especially seen this happen in the Flash community! What I do like about the MVC pattern is the emphasis on code separation and organization and not so much about implementing exactly how MVC patterned code ( as defined ) “should” operate. It’s all about the task at hand and the objects we are working with.
That said, if serializing and deserializing your model directly in your View classes works in your application, than so be it. Although, to me, and my limited understanding of what you are specifically working on, that raises a red flag. For example, what if the data source ( whether it be an RSS, a Web Service, etc. ) returned a data structure that was a far cry from the true object models in which you software operates on? And what if there are multiple services that we need to work with?
Generally speaking, I like to handle this in the Model layer of the software. The various Views and Controllers only know of specific OO Model types. What you end up with is an intermediary object that does the serializing and deserializing and interfaces directly with the data service. If you want to collect data from various sources ( as mentioned above ) you can then write additional intermediary objects that de/serialize those structures. But the important part is that the response from those data services is funneled back through those methods into a common set of Model objects. These objects are understood by the softwares VC’s and are not coupled with the data services that their properties are populated from. In a nutshell, while it may be easy to parse the XML straight in the View it will ultimately lead to tighter coupling. Just think of it this way, “What is the the responsibility of the View?”.
Again, great thoughts! I’ll check back here more often. Take care man.
JP