On Fri, Aug 12, 2016 at 10:58 AM, Andreas Joseph Krogh <andr...@visena.com> wrote:
> På fredag 12. august 2016 kl. 10:33:19, skrev Chris Travers < > chris.trav...@gmail.com>: > > > > >> >> Of course you *can* use them well. I remember talking about this with >> one author or a major ORM and he said that on thing he often does is create >> views with triggers and then use the ORM against those. This solves the >> problem above very well. But it still leaves the fact that the database >> and the application have to share an implicit understanding of an object >> model and keeping that in sync as the project grows can be troublesome. >> >> >> I don't understand why people bashing ORMs seem to think that once you >> have an ORM in you project you have to use it for everything. Of course, >> the ORM doesn't free you from using SQL directly where appropriate. IMO >> ORMs are best using for CRUD, but not for reporting or batch-processing. In >> a large project you have both, so combining is, IMO, the best. >> > > The problems I mention above occur when doing CRUD via an ORM (at least > all ORMs I have worked with). The fundamental problem is that ORMs make > for bad data management in most cases because *either* you structure your > database table structures around your object model of your application *or* > you add complexity of a logical level structured for your application. > > But either way, the database has to have intimate familiarity with the > internals of the applications using it. And there isn't an easy way around > this. > > > If you don't like your domain-model to be very close to your physical > DB-model, there's nothing preventing you from having a persistence-model, > using the ORM, and map that to/from your domain-model. However, I don't see > any of these challenges getting easier by throwing the ORM out and having > the developers handling everything themselves using SQL directly. > My preference is stored procedures plus service locators, to be honest. It enables a degree of loose coupling and even dynamic discovery that ORMs are generally not well suited to. But I think the difference may be bigger. ORMs make sense when you want a database for your application. They break down badly when you want an application for your database. Usually I tend to want the latter. > > -- > *Andreas Joseph Krogh* > CTO / Partner - Visena AS > Mobile: +47 909 56 963 > andr...@visena.com > www.visena.com > <https://www.visena.com> > > -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
