Domain Model & Persistence

In a lot of ORM domain models are coupled along with the orm mapping and persistence layer. An example of such a thing is ActiveRecord. Say you have a Post domain model using ActiveRecord. It's as simple to do post.save and the model will be persisted. The problem with this is you may want your domain model to persist to different persistence layers such as a web service, cache, or file.

With the creation of server-side javascript you can create your domain models and share them on server side and client side. The problem is they use different persistence. I was looking at Backbone.js and their models are tightly coupled with the persistence layer so I would need two separate models for each persistence layer.

TL;DR Fuck ActiveRecord

Just say no to ORM. In fact, most of the claims of database abstraction layers are lies (we'll get back to ORMs later). Let's say for instance your app use PostgreSQL. There is just no way you can "simply flip the switch" and switch to SQLite. They are both very different things. They support different feature sets, implemented differently, with different abstraction leaks. The only thing they have in common is a form of relational modeling and a somewhat similar - up to a certain degree - use of a not-so-great declarative language, SQL. In fact, two somewhat similar SQL queries in two different RDBMs can yield two different things and wildly different performance characteristics.

My advice is to just use a very light wrapper of native database APIs that lets you write SQL. The problem with over-engineered libraries like SQLAlchemy is they tend to encourage abominations such as their SQL expression API, which lets you write queries mutilated by the inexpressiveness of imperative languages.

Here's an example:

users.select(and_(users.c.age < 40, users.c.name != 'Mary'))

or how about the following:

sess.query(User,func.sum(Score.amount).label('score_increase')).join(User.scores).filter(Score.created_at > someday).group_by(User).order_by("score increase desc")

or the following, which even I can't make this shit up:

s.query(Posts).outerjoin(Posts.user).filter(Posts.post_time==s.query(func.max(Post.post_time)).filter(Posts.user_id==User.user_id).correlate(User))

You can see these abominations everywhere; perfectly normal people capable of understanding good written SQL must now deal with this nonsense: A buggy layer of ravioli code with the expressiveness nowhere near the original language it was supposed to replace. Some may say that they're not trying to replace SQL, they're just trying to normalize it in terms of the "host language" and make it more portable so to speak. We have established above that despite their name having the same three letter S Q L, they're not in any way similar, but far from it.

We can sense what they're trying to achieve here: they want the ability to build queries without having to concatenate strings - a frustrating, buggy and error-prone thing to do.

What most normal functioning people need is a simple lightweight wrapper around native database APIs that lets you do the following:

db.query('select * from articles [limit :limit [offset :offset]]', dict(limit=10, offset=100))

Do you see those [ and ] characters? wow, what a revelation! Those characters denotes that whatever is in them is optional. That's it.

Let's go back to ORM: You don't need them. simple list of dictionaries/tuples representing rows in the database is all you need. Business process is just that: process together with input and output. It's never about objects.