We’re using MySQL with Sequelize.js as the ORM.
What we’re wondering is whether a DOA layer of abstraction is worthwhile. Here are our options:
-
To use the Sequelize models throughout the application.
-
To abstract Sequelize by building a layer that converts Sequelize
models to Backbone models so that we’re using Backbone throughout
the rest of the application instead.
Is abstraction important in this case or is it normal to use Models from the ORM throughout the other layers?
2
Don’t do it. An extra layer of hand-written code will cost you far more than you think, and return far less.
Building a DAO layer is worthwhile only if: Sequelize proves inadequate, and you can’t modify Sequelize to meet your requirements, and there is another ORM that can do what you need, and the cost of building the DAO layer is less than the cost of switching your code to a new ORM.
I expect that it will cost just as much, and probably more, to create and maintain the DAO layer than you would spend later changing ORMs.
3
Even though this is a really old question, I want to add another opinion regarding using daos or not.
First of all, of course it depends. It depends on your personal likings, your style, your teams style, the expected size of the applicatio you are building and much more non functional stuff.
And, of course, there are costs. Daos do cost a lot. You need to maintain a lot of code, and you need (at least you should) test it. So why do pay for this?
- Actually, the need to test the code is no extra cost. You should have tested the same code if you wouldn’t have used the dao pattern. But with the dao pattern, it is easier to test because your unit of work just became a lot smaller. Your business code suddenly is indepentend of your query implementation. You can test both without the other by mocking the dao. How nice 🙂
- Actually, your cost to maintain the code is also no extra cost. All the extra code is just a little bit of glue code to keep it all together. The net code remains the same. Even better, encouraging code reuse can save you net code. See next point.
- If your querys are non trivial, they just became a lot easier to reuse if implemented in a dao. You do not even think about implementing it in place. Of course you are looking through your daos methods to check if you already implemented
getAllMyStuffThatHappendSinceYesterdayExplicitlyWithoutSomeEagerlyLoadedAssociation. - Edit: Another great feature of using daos is you are independent of shortcomings of the generalization of sequelize. You know your query will always return an entity and never will be undefined? Wounderfull. Your signature just became a lot more expressive compared to sequelizes
findOne(...):Promise<T|undefined>.
Also, in my personal opinion, it doesn’t matter if you implement your DAOs as first class citizens or just as “active records” within your Sequelize model classes. I perceive them as daos as well. But if you implement it as first class citizens, testing becomes way easier.