The Death of ORM Tools
-
In Marc's defense, he did state in his original reply that this was his opinion. You are perfectly entitled to disagree, but that doesn't mean that Marc's wrong - he just doesn't happen to agree with your worldview. Now, show me a current ORM that maps database tables to useful entities. I don't know of any at the moment, of course you could well prove me wrong be reeling off a list but, then again, you may not either. The biggest problem with the ORM that I've used is that they map to database tables which are often defined based on normalisation practices. This means that you end up following tortuous and convoluted object hierarchies, often loading far more data into memory than you need or you end up coding lots and lots of complex stored procedures to match an object hierarchy that isn't natural in the database, thus cutting out one of the more obvious benefits of ORM - speed of development.
Deja View - the feeling that you've seen this post before.
Apologies, I voted that post as 1 by mistake :(! I wanted to reply and agree :) lol!
James Simpson Web Developer imebgo@hotmail.com P S - This is what part of the alphabet would look like if Q and R were eliminated
Mitch Hedberg -
Apologies, I voted that post as 1 by mistake :(! I wanted to reply and agree :) lol!
James Simpson Web Developer imebgo@hotmail.com P S - This is what part of the alphabet would look like if Q and R were eliminated
Mitch HedbergThat's all right. I don't mind - you can revote if necessary.
Deja View - the feeling that you've seen this post before.
-
>>No they're not. In fact, objects are often the worst approach to solving other programming tasks. Opinions are not facts. >>Because it couples a schema with an implementation. Many activities can be accomplished without mirroring/coding the schema in classes. Im sure you are aware that most mappers support declarative mappings. Either you map db schema to a class schema, which is what ORMappers do. And if the db schema changes, you have to modify your mapping schema.. and in worst case alter your domain model.. Or you just use the dbschema directly (ad hoc, sprocs etc) And if the db schema changes.. your toast.. you have to find every stored proc or ad hoc text snippet and apply the changes in every place. Or you use black magic that just make your application know what fields and tables to access and how to query them. Which alternative do you use? >>I worked on one such application once >> Using ORM would have (provably) caused the project to fail. So because you failed, and that renders the concept bad? Thats pretty much the standard response. "well I used this ORMapper once, 300 years ago, well there was objects and a DB involved, and when I loaded an order, all the orderlines was also loaded, it was so slow" Experience, history and facts are not the same thing. ORMappers have evolved since they first appeared, and not all mappers are the same. There are still lots of simple 1-1 mappers out there. >>Because you're implying an ideal world and miss other aspects of software, such as maintainence, upgrades, product lifecycle, etc. No im not missing those aspects, the ormapped apps we build here are the ones that are the easiest to maintain and upgrade.. Btw. can you for example open up some code/script/whatever and find a enum then rightclick and select "find all references" and see every single spot in your solution where a certain status is applied.. or find every place where a certain property is set... I can.. ;-) (And yes, we have transaction support on in mem objects with the ability to rollback object state for entire graphs, notifications for every action in the mapper and we can transform queries against the domain model into presentation models) Just because other mappers might lack a few features doesnt mean that its a flaw in the ORM concept. Im NOT saying that ORMapping solves everything, it sure doesnt, it sucks for bulk operations and are in most cases overkill if you just want to present data in reports
Roger Alsing wrote:
Or you just use the dbschema directly (ad hoc, sprocs etc) And if the db schema changes.. your toast..
Not necessarily. If you're smart about it, you should be able to add tables, columns, of course modify anything the app doesn't actually use, and never even need to recompile. And, if your changes are more involved than that, you'll have to change your app ORM or not. A good ORM is essentially generating queries for you, based on the needs of your code. So it's a time-saver, something to cut the drudgery. A bad ORM is essentially a serialization framework with a DB instead of Disk as the backend. Such constructs are arguably trading a bit of drudgery up-front for a huge loss in performance and flexibility later on. There's nothing magical about ORM, or OOP for that matter. They work well enough in some scenarios to make it all worth while, but there's no good reason to hammer every program into that model.
-
>>No they're not. In fact, objects are often the worst approach to solving other programming tasks. Opinions are not facts. >>Because it couples a schema with an implementation. Many activities can be accomplished without mirroring/coding the schema in classes. Im sure you are aware that most mappers support declarative mappings. Either you map db schema to a class schema, which is what ORMappers do. And if the db schema changes, you have to modify your mapping schema.. and in worst case alter your domain model.. Or you just use the dbschema directly (ad hoc, sprocs etc) And if the db schema changes.. your toast.. you have to find every stored proc or ad hoc text snippet and apply the changes in every place. Or you use black magic that just make your application know what fields and tables to access and how to query them. Which alternative do you use? >>I worked on one such application once >> Using ORM would have (provably) caused the project to fail. So because you failed, and that renders the concept bad? Thats pretty much the standard response. "well I used this ORMapper once, 300 years ago, well there was objects and a DB involved, and when I loaded an order, all the orderlines was also loaded, it was so slow" Experience, history and facts are not the same thing. ORMappers have evolved since they first appeared, and not all mappers are the same. There are still lots of simple 1-1 mappers out there. >>Because you're implying an ideal world and miss other aspects of software, such as maintainence, upgrades, product lifecycle, etc. No im not missing those aspects, the ormapped apps we build here are the ones that are the easiest to maintain and upgrade.. Btw. can you for example open up some code/script/whatever and find a enum then rightclick and select "find all references" and see every single spot in your solution where a certain status is applied.. or find every place where a certain property is set... I can.. ;-) (And yes, we have transaction support on in mem objects with the ability to rollback object state for entire graphs, notifications for every action in the mapper and we can transform queries against the domain model into presentation models) Just because other mappers might lack a few features doesnt mean that its a flaw in the ORM concept. Im NOT saying that ORMapping solves everything, it sure doesnt, it sucks for bulk operations and are in most cases overkill if you just want to present data in reports
Roger Alsing wrote:
Opinions are not facts.
Such is the bane of software development. If I build a bridge that collapses under load, I can use clearly defined engineering principles to prove that my opinion on how the bridge was built was wrong. Software development is based on past experiences which formulates present opinion as to future development processes. Thus software development is frought with the many poor choices rather than the few good choices. <blockquote class="FQ"><div class="FQA">Roger Alsing wrote:</div>And if the db schema changes.. your toast.. you have to find every stored proc or ad hoc text snippet and apply the changes in every place.</blockquote> Well, that's my issue with ORM. It requires recompiling the application, whether it's the server or the client. And how does ORM support an n-tier environment? That's one of my issues with the Entity Framework. Are the transactions abstracted sufficiently so that I can ship them to a middleware server where I can encode rows/fields that need to be secured, where I can add auditing to fields, where I can implement a point in time architecture, where I can trigger business rules at the middleware server based on transactions against tables? I think not, but correct me if I'm wrong.
Roger Alsing wrote:
Which alternative do you use?
Interacx. Marc
-
In Marc's defense, he did state in his original reply that this was his opinion. You are perfectly entitled to disagree, but that doesn't mean that Marc's wrong - he just doesn't happen to agree with your worldview. Now, show me a current ORM that maps database tables to useful entities. I don't know of any at the moment, of course you could well prove me wrong be reeling off a list but, then again, you may not either. The biggest problem with the ORM that I've used is that they map to database tables which are often defined based on normalisation practices. This means that you end up following tortuous and convoluted object hierarchies, often loading far more data into memory than you need or you end up coding lots and lots of complex stored procedures to match an object hierarchy that isn't natural in the database, thus cutting out one of the more obvious benefits of ORM - speed of development.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
Now, show me a current ORM that maps database tables to useful entities. I don't know of any at the moment, of course you could well prove me wrong be reeling off a list but, then again, you may not either.
NHibernate does that. You design your entities as standard objects, no Hibernate base class, no special interface, no crazy attributes. And then you tell NHibernate how to map values from the DB tables into that entity. It does the SQL generation. Of course, it's not shocking that setting up NHibernate is significantly more work than other ORMs. For instance, all the mapping is done in XML files. Most of these have to be hand-coded. But, if set up correctly from the start, it's not that difficult.
-
Pete O'Hanlon wrote:
Now, show me a current ORM that maps database tables to useful entities. I don't know of any at the moment, of course you could well prove me wrong be reeling off a list but, then again, you may not either.
NHibernate does that. You design your entities as standard objects, no Hibernate base class, no special interface, no crazy attributes. And then you tell NHibernate how to map values from the DB tables into that entity. It does the SQL generation. Of course, it's not shocking that setting up NHibernate is significantly more work than other ORMs. For instance, all the mapping is done in XML files. Most of these have to be hand-coded. But, if set up correctly from the start, it's not that difficult.
David Stone wrote:
It does the SQL generation.
Which enforces a 2-tier architecture, doesn't it? The client generates the SQL and talks directly to the database, right? Or can you capture the transactions and send them to a middleware layer, feed that ack into NHibernate and have it generate the SQL from a transaction log? Marc