The Death of ORM Tools
-
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer? Is there really a place in the .NET Programming world for these third party tools now while this exists? Thanks, James
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 -
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer? Is there really a place in the .NET Programming world for these third party tools now while this exists? Thanks, James
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 HedbergI'd be wary jumping onto the Entity Framework until it's officially released (and until I'd had a chance to evaluate how useful it really is). AFAIK it's still at Beta level - hence very likely to change between now and release.
Deja View - the feeling that you've seen this post before.
-
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer? Is there really a place in the .NET Programming world for these third party tools now while this exists? Thanks, James
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 HedbergIf the ADO.NET Entity layer is anything like Microsoft's Application Blocks, then you can bet that I won't be using it because it'll be too complex. There's always room for third party tools when the first and second party can't seem to get a clue and make their software simple to use. :)
-
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer? Is there really a place in the .NET Programming world for these third party tools now while this exists? Thanks, James
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 HedbergThere will always be gaps to fill by 3rd party vendors. Im co-developing an opensource ORM (NPersist) And I'd say it still fills it purpose even if L2S and Entity framework is released. L2S is just too simple, it only supports 1-1 mapping and its blackboxed, you cannot extend it nor fix the bugs in it. Ive seen very little of EF, but as far as I understand, it will require quite a bit of special code in your entities and I've got the impression that it is bloated and not like other mappers. I would be happy if MS could release a mapper that fills all my mapping needs. but untill then, I will continue to develop my own stuff. L2S almost does that, but: 1-1 mapping , a few bugs , lack of m-n mapping , non POCO entities and 0 possibility to extend/alter it, ruins it for me...
-
There will always be gaps to fill by 3rd party vendors. Im co-developing an opensource ORM (NPersist) And I'd say it still fills it purpose even if L2S and Entity framework is released. L2S is just too simple, it only supports 1-1 mapping and its blackboxed, you cannot extend it nor fix the bugs in it. Ive seen very little of EF, but as far as I understand, it will require quite a bit of special code in your entities and I've got the impression that it is bloated and not like other mappers. I would be happy if MS could release a mapper that fills all my mapping needs. but untill then, I will continue to develop my own stuff. L2S almost does that, but: 1-1 mapping , a few bugs , lack of m-n mapping , non POCO entities and 0 possibility to extend/alter it, ruins it for me...
I'll bite. WTF is L2S?
Deja View - the feeling that you've seen this post before.
-
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer? Is there really a place in the .NET Programming world for these third party tools now while this exists? Thanks, James
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 HedbergJames Simpson wrote:
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer?
hahaha. I wouldn't touch that with a ten table database. But then again, I think ORM in general is total BS. But then again, I think the way most programming is done is total BS as well. So, what do I believe? Declarative UI's. Event and process workflows leveraging reusable, proven correct functionality. Workflow scripted to access module functionality. Abstracting the problem domain to modularize, compartmentalize, test, and access declaratively. Metadata. Documentation. Self-documentation, where the metadata can be used to generate 90% of the specifications document. Etc. Marc
-
James Simpson wrote:
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer?
hahaha. I wouldn't touch that with a ten table database. But then again, I think ORM in general is total BS. But then again, I think the way most programming is done is total BS as well. So, what do I believe? Declarative UI's. Event and process workflows leveraging reusable, proven correct functionality. Workflow scripted to access module functionality. Abstracting the problem domain to modularize, compartmentalize, test, and access declaratively. Metadata. Documentation. Self-documentation, where the metadata can be used to generate 90% of the specifications document. Etc. Marc
Marc Clifton wrote:
Declarative UI's. Event and process workflows leveraging reusable, proven correct functionality. Workflow scripted to access module functionality. Abstracting the problem domain to modularize, compartmentalize, test, and access declaratively. Metadata. Documentation. Self-documentation, where the metadata can be used to generate 90% of the specifications document. Etc.
Meanwhile, back on Planet Earth.... :)
-
I'll bite. WTF is L2S?
Deja View - the feeling that you've seen this post before.
Linq to Sql?
-
Linq to Sql?
Ah.... That explains it, although Linq 2 Sql really isn't an ORM tool in the traditional sense, and it does form part of the basis for the EF.
Deja View - the feeling that you've seen this post before.
-
James Simpson wrote:
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer?
hahaha. I wouldn't touch that with a ten table database. But then again, I think ORM in general is total BS. But then again, I think the way most programming is done is total BS as well. So, what do I believe? Declarative UI's. Event and process workflows leveraging reusable, proven correct functionality. Workflow scripted to access module functionality. Abstracting the problem domain to modularize, compartmentalize, test, and access declaratively. Metadata. Documentation. Self-documentation, where the metadata can be used to generate 90% of the specifications document. Etc. Marc
Marc Clifton wrote:
process workflows leveraging reusable, proven correct functionality
Ahem - model based workflow please.
Deja View - the feeling that you've seen this post before.
-
James Simpson wrote:
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer?
hahaha. I wouldn't touch that with a ten table database. But then again, I think ORM in general is total BS. But then again, I think the way most programming is done is total BS as well. So, what do I believe? Declarative UI's. Event and process workflows leveraging reusable, proven correct functionality. Workflow scripted to access module functionality. Abstracting the problem domain to modularize, compartmentalize, test, and access declaratively. Metadata. Documentation. Self-documentation, where the metadata can be used to generate 90% of the specifications document. Etc. Marc
>>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..
-
Ah.... That explains it, although Linq 2 Sql really isn't an ORM tool in the traditional sense, and it does form part of the basis for the EF.
Deja View - the feeling that you've seen this post before.
I've been mucking around with Linq to Sql a fair bit and, although it's limited in many ways, for simple (but not necessarily trivial) database type applications I've found it a real time saver. EF - I'm not so sure about. It looks pretty good and I'm sure it will work fine... up until the point when something goes wrong, when I'll then find myself up until the small hours of the morning trying to understand what this huge framework is doing and where it's going wrong.
-
Marc Clifton wrote:
Declarative UI's. Event and process workflows leveraging reusable, proven correct functionality. Workflow scripted to access module functionality. Abstracting the problem domain to modularize, compartmentalize, test, and access declaratively. Metadata. Documentation. Self-documentation, where the metadata can be used to generate 90% of the specifications document. Etc.
Meanwhile, back on Planet Earth.... :)
martin_hughes wrote:
Meanwhile, back on Planet Earth....
:laugh: Got my 5! Marc
-
Marc Clifton wrote:
process workflows leveraging reusable, proven correct functionality
Ahem - model based workflow please.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
Ahem - model based workflow please.
Yeah, that'll work. :) Marc
-
>>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:
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..
But really do they? See here[^] for example. OO is not a single answer for all software problems.
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe -
So, how many people have dropped their current ORM Data Access tool to adpot the new ADO.NET Entity Layer? Is there really a place in the .NET Programming world for these third party tools now while this exists? Thanks, James
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 HedbergJames 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.
-
>>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.