« Update on the Status of Catalyst 'zombie-boomstick' Release | Main | New Catalyst Release and Zombie-Boomstick Retrospective »



Feed You can follow this conversation by subscribing to the comment feed for this post.

Wolfgang Kinkeldei

Hi John,

nice to read that others are also thinking about ways to get controllers thin while keeping Catalyst-specific things out of the model.

One of the last books I have read were "Domain Driven Design" by Eric Evans (http://en.wikipedia.org/wiki/Domain-driven_design). Transporting the Domain Logic into a Catalyst App I could imagine to insert a business model layer between Catalyst Controllers and Model classes. Models could be used for all infrastructure related things like Database, File Storage, Caching, Mail-Service and many more tasks.

Eric Evans suggests a lot of patterns to build into a domain model in order to cleanly separate concerns and keep the model clean, concise and maintainable.

I am currently trying to build some base classes for creating such a layer using a subset of Evan's suggested patterns. A central part of this layer is a configuration-driven class [accessed via $c->model('Domain')] based on Bread::Board. This way, one could group related queries into services and build entities acting as expanded (or proxies to) DBIC-Row objects with built-in logic that glues together DBIC and other models if needed. Currently I am torn about the granularity of the base-classes to offer. Evans cleanly separates Factories (for initially building objects), Repositories (for retrieving objects from DB) and Entities (the objects themselves) as well as Aggregates (extended Entities for public access). As DBIC offers many things the Java-counterparts do not seem to provide, one could omit Factories and Repositories, currently I am usure...

My first (still very pre-alpha) tries can be found here: https://github.com/wki/DDD


Caleb Cushing ( xenoterracide )

@Wolfgang checkout our Implementing DDD by Vaughn Vernon when you're done.

As far as models that are context aware. You don't want your model to have a dependency on catalyst context object, rather you might, in the controller, derive from the context what you need into model terms and pass those pieces into your model. (you could do this with a factory that takes the context object and provides you with your model, it's basically another take on Dependency Injection )

The real trick is to understand the "Ports and Adapters" architecture
. This will ensure that both catalyst and your persistence are well abstracted.

Wolfgang Kinkeldei

Thanks alot for the your advice. I just purchased the book and start reading now :-)

Piers Cawley

One thing I've been experimenting with as a mechanism for narrowing broad context objects down to the requirements of a particular model is through the use of type coercions. In general, a model that needs to be aware of context only needs a small fraction of that context so I'll make a class with that small interface, then define an associated type and a coercion from the Catalyst stash into this narrower context.

Things can still end up coupled, but there's now an explicit place (the definition of the new context class) that describes what context is being exposed to the model. It also helps with testing because, once I've tested the coercion does what's expected, I can just construct instances of the narrower context when writing tests. I generally find that the sooner I can get from a general data structure to a tightly specified object, the happier I am.

The comments to this entry are closed.