The Death of ORM Tools
-
>>I think ORM in general is total BS In what way? You do use object oriented languages, don't you? If objects are good enough for you to solve other programming tasks, why wouldnt objects be good enough when dealing with business oriented problems? And even if you don't do normal OOP but aim more for process oriented designs etc: If the application developed works, and fills the needs of the customer, and was delivered on time and budget. How can you then claim that the design or concept behind it is BS? "That application is pure BS!" "uh, but it works, its right there, doing what it should" "But I dont like the way it works" "why?" "Its just wrong!" "but it does its job, it does everything its supposed to" "Its still wrong!" Even if you throw a gazillion arguments why it is wrong, it still doesnt change the fact that shitloads of applications are built that way, and do their job just fine..
Roger Alsing wrote:
You do use object oriented languages, don't you?
OOP has its purposes, but is generally way overrated. I've found OOP has its place in a framework that supports non-OOP metaprogramming, and that that approach is superior to harcoding state, workflow, etc. <blockquote class="FQ"><div class="FQA">Roger Alsing wrote:</div>If objects are good enough for you to solve other programming tasks</blockquote> No they're not. In fact, objects are often the worst approach to solving other programming tasks.
Roger Alsing wrote:
why wouldnt objects be good enough when dealing with business oriented problems?
Because it couples a schema with an implementation. Many activities can be accomplished without mirroring/coding the schema in classes. There are of course exceptions, and then ORM is an appropriate tool.
Roger Alsing wrote:
If the application developed works, and fills the needs of the customer, and was delivered on time and budget.
:laugh: Show me that and I'll show you a blue moon. I worked on one such application once, and we scripted all the workflow and tossed out the ORM the database group was generating and relied on a few simple reusable patterns for working with the data. That resulted in success. Using ORM would have (provably) caused the project to fail.
Roger Alsing wrote:
How can you then claim that the design or concept behind it is BS?
Because you're implying an ideal world and miss other aspects of software, such as maintainence, upgrades, product lifecycle, etc. My 2c. :) Marc
-
Roger Alsing wrote:
You do use object oriented languages, don't you?
OOP has its purposes, but is generally way overrated. I've found OOP has its place in a framework that supports non-OOP metaprogramming, and that that approach is superior to harcoding state, workflow, etc. <blockquote class="FQ"><div class="FQA">Roger Alsing wrote:</div>If objects are good enough for you to solve other programming tasks</blockquote> No they're not. In fact, objects are often the worst approach to solving other programming tasks.
Roger Alsing wrote:
why wouldnt objects be good enough when dealing with business oriented problems?
Because it couples a schema with an implementation. Many activities can be accomplished without mirroring/coding the schema in classes. There are of course exceptions, and then ORM is an appropriate tool.
Roger Alsing wrote:
If the application developed works, and fills the needs of the customer, and was delivered on time and budget.
:laugh: Show me that and I'll show you a blue moon. I worked on one such application once, and we scripted all the workflow and tossed out the ORM the database group was generating and relied on a few simple reusable patterns for working with the data. That resulted in success. Using ORM would have (provably) caused the project to fail.
Roger Alsing wrote:
How can you then claim that the design or concept behind it is BS?
Because you're implying an ideal world and miss other aspects of software, such as maintainence, upgrades, product lifecycle, etc. My 2c. :) Marc
>>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
-
James Simpson wrote:
Is there really a place in the .NET Programming world for these third party tools now while this exists?
Hell yes. Is there room for 3rd party grid controls since Microsoft started supplying one?. Yup. If it winds up being like everything else Microsoft supplies, they'll have a lot of API, but very little of the hooking-the-bits-together-so-it-works-in-real-world-situations. Cheers, Drew.
Yea, good point... Im actually trying to figure out a good argument for our in house ORM that we use on a number of products. A Coulple of developers went to a MS Virtual Earth Conference day and came back asking why we are not using LinqToSql or the new entity framework. My argument was ours is simpler, and linqtoSql was only in an early beta when we needed. I now need to decide wether we continue with the inhouse ORM or take on LinqToSql/Entity Framework. After spending 10 minutes knocking up an example in our ORM and then spending half an hour not even getting anywhere with LinqToSql, I decided that we should problem give our ORM a bit more credit ;) Anyway.. here I go to implement a Linq Provider lol! Ta
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 -
>>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
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.
-
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.
-
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.
-
>>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
-
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