ORM Rant
-
At the end of the 90ties we somehow got into ORM. At the time - no matter how hard we tried - we always ended up with a messy and complicated code and filthy compromises. And it hasn't changed. But somehow frameworks like NHibernate and EntityFramework are becoming very popular. So here is my rant. Some time ago I worked on large projects and things were pretty predictable. You've got DB model. You generate your SQL procedure layer and your C# layer. Then you create your component / web service / wcf service / restful service and serialize results of your C# calls as POCOs. Now try to do this with fancy NHibernate objects with auto-resolving proxy objects for related entities. It won't work. Because when objects are serialized their auto-resolving lazy evaluating proxies aren't. To solve it you duplicate /I'll write it again, for drama effect: duplicate/ your objects to create serializable POCOs. And then you create them CRUD functions on top of object models. Or even separate the entities /drama: dereference them having no two entities connected/... And, hey, you are back where you were with the stored procedures - only with lousier performance and three layers of crap on top of it. So next time someone comes with a fancy-schmancy ORM wrapper it better already include web service / wcf service or restful service abstraction and work on top of it; rather then bellow it! Because otherwise we just off-load drudgery to the web services and call it "business layer" when in fact it is really a freaking "ORM back to stored procedures layer." There. Hhhh...shhhh... I already feel better.
-
At the end of the 90ties we somehow got into ORM. At the time - no matter how hard we tried - we always ended up with a messy and complicated code and filthy compromises. And it hasn't changed. But somehow frameworks like NHibernate and EntityFramework are becoming very popular. So here is my rant. Some time ago I worked on large projects and things were pretty predictable. You've got DB model. You generate your SQL procedure layer and your C# layer. Then you create your component / web service / wcf service / restful service and serialize results of your C# calls as POCOs. Now try to do this with fancy NHibernate objects with auto-resolving proxy objects for related entities. It won't work. Because when objects are serialized their auto-resolving lazy evaluating proxies aren't. To solve it you duplicate /I'll write it again, for drama effect: duplicate/ your objects to create serializable POCOs. And then you create them CRUD functions on top of object models. Or even separate the entities /drama: dereference them having no two entities connected/... And, hey, you are back where you were with the stored procedures - only with lousier performance and three layers of crap on top of it. So next time someone comes with a fancy-schmancy ORM wrapper it better already include web service / wcf service or restful service abstraction and work on top of it; rather then bellow it! Because otherwise we just off-load drudgery to the web services and call it "business layer" when in fact it is really a freaking "ORM back to stored procedures layer." There. Hhhh...shhhh... I already feel better.
-
Please do not use the technical forums for this type of post, use the Soapbox or Lounge. See http://www.codeproject.com/Messages/1278600/How-to-get-an-answer-to-your-question.aspx[^].
Is it possible to use your admin Harry Potter powers to move the entire thread there? I can't seem to be able to do that...please. :)
-
Is it possible to use your admin Harry Potter powers to move the entire thread there? I can't seem to be able to do that...please. :)
-
Is it possible to use your admin Harry Potter powers to move the entire thread there? I can't seem to be able to do that...please. :)
Don't worry, think of it as a suggestion for the future.
Wrong is evil and must be defeated. - Jeff Ello[^]
-
Please do not use the technical forums for this type of post, use the Soapbox or Lounge. See http://www.codeproject.com/Messages/1278600/How-to-get-an-answer-to-your-question.aspx[^].
Wat, are you kidding, the Lounge is exactly the place for a good rant about the tech we have to use, I suggest you clarify that with the OP. [edit] oops I thought I was in the Lounge :doh: I'll just remove that foot![/edit]
Never underestimate the power of human stupidity RAH
-
At the end of the 90ties we somehow got into ORM. At the time - no matter how hard we tried - we always ended up with a messy and complicated code and filthy compromises. And it hasn't changed. But somehow frameworks like NHibernate and EntityFramework are becoming very popular. So here is my rant. Some time ago I worked on large projects and things were pretty predictable. You've got DB model. You generate your SQL procedure layer and your C# layer. Then you create your component / web service / wcf service / restful service and serialize results of your C# calls as POCOs. Now try to do this with fancy NHibernate objects with auto-resolving proxy objects for related entities. It won't work. Because when objects are serialized their auto-resolving lazy evaluating proxies aren't. To solve it you duplicate /I'll write it again, for drama effect: duplicate/ your objects to create serializable POCOs. And then you create them CRUD functions on top of object models. Or even separate the entities /drama: dereference them having no two entities connected/... And, hey, you are back where you were with the stored procedures - only with lousier performance and three layers of crap on top of it. So next time someone comes with a fancy-schmancy ORM wrapper it better already include web service / wcf service or restful service abstraction and work on top of it; rather then bellow it! Because otherwise we just off-load drudgery to the web services and call it "business layer" when in fact it is really a freaking "ORM back to stored procedures layer." There. Hhhh...shhhh... I already feel better.
In 2005, I inherited a project which made use of NHibernate. Wow, did that look fancy! How easy you could add data to a datagrid and move in along foreign key relationships... But there was a catch (no, it did not return 22): every foreign key relationship was treated with referential integrity by NHibernate, even when there was no referential integrity designed into the database. And working in a really-existing company of today's capitalism, reality did not always match theory (that's way we could not use the referential integrity on the database). We had big problems when data had to be inserted into a "dependent" table while the corresponding data in the "master" table were not yet present... With that experience, I still do avoid ORM, though I believe things might be less cruel nowadays.
-
Wat, are you kidding, the Lounge is exactly the place for a good rant about the tech we have to use, I suggest you clarify that with the OP. [edit] oops I thought I was in the Lounge :doh: I'll just remove that foot![/edit]
Never underestimate the power of human stupidity RAH