Straw poll: ORM - worth it for a small project?
-
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I work in this realm all the time and after a lot of study and testing I've found ORM is almost never a good idea. The reason being is that it's not really ORM at all, it's TOM Table Object Mapping and a single table never properly represents the complexity of a real world object. If you are taking end user happiness into consideration you want to hide them from the underlying complexity of the data used to store that object. An end user doesn't want to know that a Customer is actually a table of customers, a table of postal codes, a table of phone numbers etc etc and using an ORM most often results in an interface that looks like a front end for a sql server manager. I think they are great if you are an outsourcer trying to crank out code as fast as the laws of physics will allow but if you take pride in your work and want something that the end user finds relates to the real world and makes intuitive sense avoid them like the plague.
"110%" - it's the new 70%
-
I vote for code generation. :cool:
Heh... well, do you have a particular recommendation? Obviously, if i'm using a tool to generate code for me, it should result in less work than just sitting down and writing the code myself... The problem i have with the code generators i've looked over so far (limited to MyGeneration and whatever the thing built into VS is called) is that they tend to produce direct mappings between tables and collections of objects - which doesn't exactly get me very far.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
I work in this realm all the time and after a lot of study and testing I've found ORM is almost never a good idea. The reason being is that it's not really ORM at all, it's TOM Table Object Mapping and a single table never properly represents the complexity of a real world object. If you are taking end user happiness into consideration you want to hide them from the underlying complexity of the data used to store that object. An end user doesn't want to know that a Customer is actually a table of customers, a table of postal codes, a table of phone numbers etc etc and using an ORM most often results in an interface that looks like a front end for a sql server manager. I think they are great if you are an outsourcer trying to crank out code as fast as the laws of physics will allow but if you take pride in your work and want something that the end user finds relates to the real world and makes intuitive sense avoid them like the plague.
"110%" - it's the new 70%
John Cardinal wrote:
The reason being is that it's not really ORM at all, it's TOM Table Object Mapping and a single table never properly represents the complexity of a real world object.
Heh. That's exactly the conclusion i've reached in my, uh, going on eight hours of ORM research. I was kinda hoping there was something i was missing. Thanks. :)
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
John Cardinal wrote:
The reason being is that it's not really ORM at all, it's TOM Table Object Mapping and a single table never properly represents the complexity of a real world object.
Heh. That's exactly the conclusion i've reached in my, uh, going on eight hours of ORM research. I was kinda hoping there was something i was missing. Thanks. :)
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Shog9 wrote:
I was kinda hoping there was something i was missing
Nope you got the gist of it. I've actually been considering building an application that I can use to build data driven apps, kind of like an ORM but you start with the object and the db is generated for you using as many tables as it requires for the object and it's child and grandchild objects and collections automatically. I really think that's the way to go, to generate biz object classes from datatables is exactly backwards.
"110%" - it's the new 70%
-
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I'm with John equating a row from a database table with an object doesn't really make sense. When I've been able to choose the approach, I've been happiest with writing stored procedures as the interface to the database and then using a tool to generate a data object with methods corresponding to the procedures.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Big wodge of SQL. In an OLTP project, any time spent building an object model so you can retrieve one piece of data from it is wasted time. You need to get the database schema designed and optimized for fast retrieval of data and fast updates, and that is difficult to do with ORM. We now produce solutions for in-store price lookups/markdown relabelling/stocktaking for some large UK retailers, using hand-held computers interactively. The aim is to get sub-second request turnaround time, and scale to at least 3000 devices performing requests ('think time') every 20-30 seconds. That means 6000-9000 transactions per minute or 100-150 per second. Creating an internal object model would not improve productivity particularly, and could easily harm performance.
Stability. What an interesting concept. -- Chris Maunder
-
I'm with John equating a row from a database table with an object doesn't really make sense. When I've been able to choose the approach, I've been happiest with writing stored procedures as the interface to the database and then using a tool to generate a data object with methods corresponding to the procedures.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
Andy Brummer wrote:
I've been happiest with writing stored procedures as the interface to the database and then using a tool to generate a data object with methods corresponding to the procedures.
Hmm... Generally, i hate writing stored procs even more than i hate writing SQL; maybe i'll give 'em another look though.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Big wodge of SQL. In an OLTP project, any time spent building an object model so you can retrieve one piece of data from it is wasted time. You need to get the database schema designed and optimized for fast retrieval of data and fast updates, and that is difficult to do with ORM. We now produce solutions for in-store price lookups/markdown relabelling/stocktaking for some large UK retailers, using hand-held computers interactively. The aim is to get sub-second request turnaround time, and scale to at least 3000 devices performing requests ('think time') every 20-30 seconds. That means 6000-9000 transactions per minute or 100-150 per second. Creating an internal object model would not improve productivity particularly, and could easily harm performance.
Stability. What an interesting concept. -- Chris Maunder
Mike Dimmick wrote:
You need to get the database schema designed and optimized for fast retrieval of data and fast updates, and that is difficult to do with ORM.
I'm expecting well under 100 updates each day, so as long as each update completes in a reasonable amount of time (< 2 sec.) i'll be fine. Retrieval has to happen fast though; this is aimed at developers, and i'm probably gonna have to twist a few arms to get them to look at the thing - delays are an excuse i just don't wanna hand anyone, especially myself (since i'll jump at the chance to blow off a day of work optimizing queries... ;P ) Thanks
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Andy Brummer wrote:
I've been happiest with writing stored procedures as the interface to the database and then using a tool to generate a data object with methods corresponding to the procedures.
Hmm... Generally, i hate writing stored procs even more than i hate writing SQL; maybe i'll give 'em another look though.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Try writing a CLR stored proc. You'll really enjoy that, you can use C# and everything.
Last modified: 32mins after originally posted --
-
Try writing a CLR stored proc. You'll really enjoy that, you can use C# and everything.
Last modified: 32mins after originally posted --
Brady Kelly wrote:
You'll really enjoy that, you can use C# and everything.
For queries? How does that work?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Andy Brummer wrote:
I've been happiest with writing stored procedures as the interface to the database and then using a tool to generate a data object with methods corresponding to the procedures.
Hmm... Generally, i hate writing stored procs even more than i hate writing SQL; maybe i'll give 'em another look though.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Shog9 wrote:
i hate writing SQL
Seriously, you shouldn't program for a database. :suss: Why not switch to game programming?
-
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I'd vote for object mapper Justin and I wrote: Part I[^] Part II[^] Give it the schema, let it generate the code, and off you go. OK, you do have to manage the relationships yourself, but with 10 tables, that shouldn't be too complicated. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Brady Kelly wrote:
You'll really enjoy that, you can use C# and everything.
For queries? How does that work?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
It would be a royal waste of time, and PITA, to write CLR stored procs for queries. I've added the joke icon now. However, if you must know, you would query using normal ADO methods, with the connection string "context connection=true" and then return the results using SqlPipe.SendResultsRow.
-
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I have friends who swear they will never work without an ORM again. I reckon if you know one, it's worth it for a small project, if you don't, it's probably not worth learning one for a small project.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Shog9 wrote:
I was kinda hoping there was something i was missing
Nope you got the gist of it. I've actually been considering building an application that I can use to build data driven apps, kind of like an ORM but you start with the object and the db is generated for you using as many tables as it requires for the object and it's child and grandchild objects and collections automatically. I really think that's the way to go, to generate biz object classes from datatables is exactly backwards.
"110%" - it's the new 70%
Uh . . .ORM, as in NHibernate, does exactly what you talk about building. Given a bunch of classes, it generates the table schema. Not only that, it provides you with a manager object that you use to save, query and delete objects. It enforces all of your constraints. Manager.Save(obj). Manager.Find(type, id). Manager.FindAll(type, string). Manager.Delete(obj). You get the idea. All of the tables, columns, relationships, dependencies and constraints are marked up in code as .NET attributes. You never need to write a single line of SQL unless you want to optimise a particular query (in which case, the ORM tool will happily use your supplied one). Furthermore, the ORM layer provides a distributed runtime cache, which it flushes on its own schedule (all configurable of course) so that half the time you never even HIT the database when making a query. ORM wins EVERY TIME, if you ask me. There's a bit of a learning curve, to specify the mappings so the tool does what you want. After that, it's a programmers dream. Just don't expect to make friends with any DBAs after you start advocating for it :-) All of the disadvantages you have listed simply don't apply in the ORM world. That's the whole point. I think you're thinking of code generation.
-
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
What do i say, well i think that the easy way to anything isnt alwaays the proper way, i myself prefer to sit down the old way and write the code myself ,why? in doing so there is a greater sence of accomplishment and knowing that your not puting up the front that you got it done but did you get it done right! so my vote is for good work and not the easy way out on a project, i've worked on over 200 video game projects and fount that to me, it was more efficent on clarity of knowing the functios that you wrote are going to work because you wrote the code. Note* trial and error is some times the best teacher:)
peace-0ut
-
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I vote 8 for DB40bjects :) Seriously, if the App and DB isn't huge, why not skip the ORM/OPF and RDBMS scenes altogether?
-
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I was looking at ORMs somewhere in January this year, because I just started working on a CRM system for one of my clients. I decided to give EntitySpaces (no one mentioned it!) a try (there is a trial version you can download) and bought it a week later or so. ;) I can only say that EntitySpaces is a lot better than using DataSets built-in Visual Studio. Moreover, EntitySpaces is a MyGeneration architecture (Mike Griffin along with a few other guys created both) and so you get ORM + code generation. Changing database model requires you to run MyGeneration script and you're ready to go. Everytime, just run one script. It supports databinding, all classes are generated as partial, so you can write your own logic not touching the generated files. My CRM has 18 tables so far, but it will be growing. I don't use ORM for databases with 5 tables or so, but for databases with over 10 tables I must say it helps me a lot and I write something like:
private void GetLinkedStates() { statesCollection = new StatesCollection(); statesCollection.Query .Where(statesCollection.Query.Country.Equal(cbCountries.SelectedValue)) .OrderBy(statesCollection.Query.StateName.Ascending) .Load(); statesCollectionBindingSource.DataSource = statesCollection; }This query gets all states for a country selected currently in a combobox, sorts them in ascending order and binds to a BindingSource (yeah, I know - I called it cbCountries, that was before I read MSDN guidelines for naming :P guess it's a refactoring candidate). Anyway, take a look at EntitySpaces[^], get a trial and see for yourself. I am not connected with ES, just a happy customer. :) -
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I would advice not to use ORM: for the savings it _might_ bring you, I'd say it's not worth both the risk of running into serious limitations, and also the learning curve. In the project we're doing now, the database layer code amounts to about 7% of the line count, much of which I don't see how it would be done using an ORM. We've modeled things like inheritance in the db, we use temporal tables, we update rows while checking for concurrency issues using a row version id. Though it's a bit more work writing it out manually, an ORM would never have given us the control we need, and the performance that plain ADO.NET gives us. Also every single ORM is intrusive in the class model world. NHibernate e.g. requires to use their own collection implementation, while we use our own active collections, so that would have been another road block.
Wout
-
Yeah, i'm back to stumbling around clumsily with a database. :-O And faced with the task of managing relationships and mappings to useful objects, i'm starting to wonder if there's any gold to be found in any of these ORM systems. NHibernate, IBATIS, Gentle.NET, etc. all talk a good game, purporting to do exactly what i want... and yet, once i start diving into the documentation, i'm left wondering if churning out a page of metadata for each class is really any easier than just writing the SQL and managing dependencies myself. I'd probably give that Linq stuff a try, except that i need this to actually run on things that aren't my machine. See, this isn't a large system. Normalized, there are only ten tables + an xref table. There'll never be more than 4-5 separate clients, two of them web clients, and i'll probably build all DB communication and "biz-logic" into a single shared DLL. Frankly, i just want to get the DB stuff out of the way so that i can start doing the fun UI stuff... So, here's the poll: vote 1 for ORM, and reply with your reasoning. Vote 5 for "big wad of SQL". Vote 3 for "use VBA in Access"... then run away fast.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I voted 1 for ORM but only because you said it was a small project. As much as I like using Ruby on Rails and its ORM (ActiveRecord) I am running into big performance issues which are a result of the ORM. I've ended up writing so much of my own SQL that I might as well not be using ActiveRecord at all. A shame but there you go.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...