Tuesday, July 31, 2012

Catalyst done wrong


     Perl fans enjoy their language because it allows them to be
     expressive. As such, for better or for worse, we aggressively
     defend our right to do it our way. One place where this
     attitude should be left at the door is with frameworks such as
     Catalyst.
   
     Catalyst can easily be thought of as an easier way to make a web
     app. while this is certainly true, it is more accurate to say that
     it is a means of delegating basic web application architecture
     decisions.  The delegation of directory and namespace structure
     and these built in methods certainly make things easy, but the
     fact of the matter is that this is a mere side-effect.

     This is important because these architecture decisions are made
     for a reason; to separate the logic, database, and markup. While
     this is certainly not everyone's cup of tea, it allows one to
     focus on one of these fundamental components at a time; and keeps
     us from asking that age old question: Is that stray quotation
     mark coming from the html, the query, or my Perl?
     
     Unfortunately, I keep finding myself working on Catalyst code
     that for one reason or another decides to re/undo some of these
     architectural decisions.

     For example, I've seen cases where people decide that that they
     should slice some logic out of the controller and put it into a
     new directory.  They put it at the same level as the model view
     and controller. This always seems to over-compartmentalize the
     code. The caveat of mvc is that you have to manage your app in
     three different places. Why do I need a fourth?

     Then they create libraries the way you would in an intro to Java
     class where a class is a noun and all of the actions it performs
     are verbs.  What results is a cancer that grows out of control.

     As the application slowly metastasizes, The library names don't
     match the database tables and there are always more and more
     excuses to create more mvc inconsistent modules. The result is an
     undocumented abomination that lacks the consistency of the rest
     of the application

     Developers who do this aren't awful for doing this. On the
     contrary, they are applying well accepted best practices to their
     creations. They want to architect their own application; which
     doesn't work so well when the application you are working on has
     already been architected. So if you are working on a catalyst app
     and you find yourself wanting to try any of the above, do
     yourself a favor; choose a more flexible framework or roll your
     own.

3 comments:

  1. Are they perhaps building a model that is more than just a database layer? I think of Catalyst as an MVC Web Framework that includes some IoC aspects, but that doesn't mean don't build a domain model layer that is completely abstracted from the Web. Of course simple Catalyst Transaction Scripts that are little more than a database Model, View, an Controller, such as the tutorial teaches isn't necessarily wrong either, but as you get more complex, that can be hard to scale (code wise) and poorly models business logic. Also sometimes the database is poorly designed, or because it's relational and not Object Oriented is not able to be modeled as objects in the same way.

    I am currently working on building a Domain Model, with a IoC (BB) container, and a Unit of Work, which will sit underneath of some web framework. I don't really care what, I suspect it will be Mojolicious, but it could be Catalyst for all I care.

    I do not think this is wrong, in fact I suspect it is a much better design than letting your framework be "everything".

    ReplyDelete
  2. What exactly is wrong with writing classes that are nouns, and all of the actions being verbs?

    And can you explain how that might result in the code "growing out of control" ?

    ReplyDelete
  3. Nothing in and of itself. The problem lies in that Catalyst abstracts classes along the lines of the data model. If one decides to abstract classes in a different way, you end up with the proverbial "third arm" that ends up being it's own application. I explain this in the succeeding paragraph (apologies if I was not clear enough)

    As a matter of taste I don't like abstracting with nouns and verbs that aren't really tied to anything in code land. Car application code is not a car. Pretending it is forces you to tie your methods to real world objects (gas pedal, stick shift etc.) that don't necessarily exist in code. On the other hand, tying your abstractions to a data model keeps you in the familiar territory of a schema and any abstraction can be limited to the reading, writing, or manipulation of data in relation to that schema. So just enough abstraction to provide a consistent interface, not so much that you are building castles in the sky.

    ReplyDelete