Perl: Separating the persistence and the business model layers - Part 1

Today, thanks to modern Perl technologies a growing number of Perl project use DBIx::Class to access the database, and a MVC engine, such as Catalyst or other frameworks and a nice template engine to expose the application on the web. Usually, the framework tutorial assumes that you will use DBIx::Class to access and store your objects from your MVC controller. I think this approach is wrong for the following reasons:

- DBIx::Class is a perfectly fine ORM mapper but it's not a business model framework. You can add business code to the result Classes but what happens if you want to migrate some of your stuff to a NoSQL storage? Or change the way some stuff is stored in the DB. Things can and will get ugly.

- Dbic objects do not provide the flexibility you would need to implement common object oriented patterns. What if you want to use Roles, enforce interfaces, implement your own search facility? You'll eventually get so much application business code in your Dbic object that they will no longer look like dbic objects.

- Your web framework is directly fed with the ORM model, and because you want to code things quickly, you start putting business code in your controller, and this business code assumes you're using this or that ORM. And the rest will come. Web applications are difficult to test for regressions, especially if they use Ajax. Things will break without being detected before release, you will fix them quickly in your controller, and as time goes on, your shiny new application using modern Perl technologies will end up being as difficult to maintain as a good old CGI mud-ball.

- What if you want to turn your application into an API? Or if you want to make command line tools for quick administration, or for asynchronous runs? Well you can't. Because the your business logic is scattered everywhere, in all the layers of the application.

What we end up with this approach is our persistence layer and our MVC layer (and in the worst case our template layer) become polluted with a blob of sloppy hard to maintain business model code. Also the sad thing is that your business code IS your business' added value, so it shouldn't be considered polluting something else. I don't think MVC's and ORM's are designed to be the natural container of your business code. I think they should be kept, and loved, and used for what they are: an easy and fast way of making non-business related code thin and minimalistic.

Blob of business code longing for a home on its own

For the development of libsquare.net, I've designed a reasonably fast and easy solution to this problem. I'll be talking about it in the next part of this sequence.

XeTeX: Breaking long lines of Japanese (and Chinese) text.

While LaTeX/XeTeX is very good at hyphenating Latin words, I recently came across the problem of overflowing boxes when attempting to typeset a long paragraph consisting exclusively of Japanese characters:

母親が育児を放棄した末、大阪市西区のマンションで幼い姉弟が亡くなった事件。多くの住民が異変に気づきながら、児童相談所（児相）に通報したのは１人だけだった。複数の人が通報していれば、児相の危機感も強まったかもしれない。なぜ通報をためらった


When you render this with XeTeX, you've got a warning that your hbox is overfull, and the rendered result shows an awful truncated Japanese line:

Rendering of an non hyphen-able Japanese line

We clearly need to fix this, because most of the time your data will be in the form of a long paragraph without any linebreaks.

In XeTeX-notes.pdf, we learn that we can activate the line-breaking in XeTeX by using:

\XeTeXlinebreaklocale"en"

The locale used doesn't matter much, the important thing is that it activates line breaking for too long lines where the hyphenation mechanism cannot do its job (a long Japanese/Chinese line for instance).

By adding this to your preamble, here's what you get:

A Japanese paragraph with line breaks.

Et voilà, lines are broken so all the characters fit in the page width!

Ps: Thanks to Google news Japan for providing example data.