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.
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.
ReplyDeleteI 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".
What exactly is wrong with writing classes that are nouns, and all of the actions being verbs?
ReplyDeleteAnd can you explain how that might result in the code "growing out of control" ?
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)
ReplyDeleteAs 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.