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 dont know what you are doing, and I dont know where your project will end up. I dont know the SDLC of your project. So, I vote 1,3 and 5 until I know. I dare say most people will say, "Choose 1, cause I dont like 5" or "Choose 3 because I think it works better than 1". No one can take a quick vote on what you are doing, until one has a clear understanding of what you are doing and what you are trying to achieve. You say a small system, but will it grow? You want to do the UI stuff, but will you depend heavily on middleware and back end to provide the data accurately? Will your UI be the sole provider to the back end? Will UI also provide the business logic? Is reuse important? ....the list goes on.
-
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 am involved with a project right now that uses a fair amount of SQL. An outside web development group designed most of the site and used all of the "latest" technologies. Basically what we ended up with is an unmaintainable mess. The DB code is all in NHibernate. One of our in-house developers is afraid to change any of the DB layer because it breaks easily. When we're done with the current cycle, we're going to convert it over to raw SQL and use the Enterprise Library. One of the biggest problems with ORM tools is that the relations they come up with are mostly simplistic. Most of the generated queries return all of the fields in a table instead of just the handful that are needed. If you need to build custom relations, look out! Oh, you want to change one row in the schema? Rebuild your ORM layer! My experience has been that ORM tools increase the amount of work I have to do and decrease the amount of knowledge I have of the database itself. I prefer to leverage the Enterprise Library to make writing queries more straightforward and simply write exactly what I need. The queries are more efficient, and I end up with something that might actually be portable to other database engines.
-- Paul
-
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
The main reason that I like them is that they give a finite list of operations that are performed on the database so when I setup indexes I know how each of the columns are used just by looking at the database. I don't have to profile the application or figure out what SQL is generated by it. It's definitely not something I consider essential it just fits my way of working.
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
-
I vote 8 for DB40bjects :) Seriously, if the App and DB isn't huge, why not skip the ORM/OPF and RDBMS scenes altogether?
-
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%
There are many orm tools that are nothing more than simple mappers, code generators, or some combination. Much of these leaving you wishing you didn't drink the coolaid. However, tools like nHiberante provide transparent persistence (really the only type of ORM to purseue in my opinion) with multiple mappings patterns that don't require code annotation, code generation, or code injection. Additionally, these tools usually provide many deployment options so you can optimize your usage but provide more flexibility if needed. The learning curve is not a stroll in the park but certainly isn't Mt. Everest either. The most complicated things are 1) learning the concepts (sorta like a procedural person moving into the object world) 2) Project setup (can be simplified by providing a bit of framework code that handles setup and configuration and a GUI tool for those that don't like twiddling in xml for the mappings). 3) Using the correct design patterns to simplify usage and correct separation of concern in the application. Every place I have been, there have been those that thought a code generation, hand coding, or some wrappers on top of DataSets was faster, better, etc. Every time, I have shown that projects came in 30% faster with fewer bugs in the persistence layer and were able to accomodate late stage changes that wrecked the similar endeavor on another project. Finally, an ORM is always the right method for all forms of access to a database. If you have complex queries or a need that's best done in the database then most certainly you should hand code that since the goal here is not to replace the developers intelligence but instead focuse that intelligence on the business problem and not plumbing code.
Don Eddleman Principal Enterprise Architect Healthways
-
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
ORM is a nice idea in theory but in reality it is a "layer of distraction" with high overhead. Like most such tools, ORM came about because some people thought it a good idea to use objects to represent data instead of just result-sets. Problem is, ORM takes a lot of extra time and effort to implement and extra time and effort to maintain. If you want to use pure objects to represent data than don't waste your time with ORM or a relational database (not that there is naything wrong with RDBMSs) and use an object-oriented database such as Cache from Intersystems. IT will save you a lot of headaches in the end...
Steve Naidamast Black Falcon Software, Inc. blackfalconsoftware@ix.netcom.com
-
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.
It depends on your approach. For example, I use NHibernate for almost all of my projects. With NHibernate, you can start from tables and generate objects or you can start with objects and generate tables. The former approach generally leads to a TOM feeling, but the latter approach is where the power of ORM lies, imo. I start a new project by modeling the problem with objects - as complex as needed for the task at hand. I then use NHibernate to handle all of the database persistence. While NHibernate does have its limitations, I find that I'm generally able to map my real-world objects quite nicely. While a single table rarely represents the complexity of a real-world object, multiple tables and the relationships between those tables can. NHibernate is great because I don't have to write/maintain any SQL - but I do have the flexibility if needed. It includes a caching mechanism that is configurable and provides lazy loading. In short, once I create my objects, my DAL comes basically for free. The tradeoff? As has been mentioned, there is a learning curve and you have to evaluate whether the increase in 'intellectual complexity' is worth the benefits that ORM provides.
-
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
Real Programmers... program. VB Programmers... generate. Who do you want to be?
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles. -
Shog9 wrote:
i hate writing SQL
Seriously, you shouldn't program for a database. :suss: Why not switch to game programming?
I've done game programming, it was fun. But right now, i need this, and sometimes i gotta do things i don't like to get what i need... ;)
----
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
-
The main reason that I like them is that they give a finite list of operations that are performed on the database so when I setup indexes I know how each of the columns are used just by looking at the database. I don't have to profile the application or figure out what SQL is generated by it. It's definitely not something I consider essential it just fits my way of working.
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 don't have to profile the application or figure out what SQL is generated by it.
Ya, that makes sense. Point.
----
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 )
Christian Graus wrote:
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.
Heh. My secret reason for asking the question was, if it's worth doing, i'd rather do it first on a small project with no fixed deadline (well, ok, there was, but it was like half a year ago and no-one's bugged me...) than on a project i actually need done in short order. But i gotta say, i'm having a hard time finding any concrete reasons to try it. I use the "your life will be 100-times better with this product!" rational, i don't actually buy it... ;)
----
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...
Paul Watson wrote:
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.
Yeah... that's not good. And sure, it's a small project, but i'm to be a user as well as a developer - and i don't tolerate slow apps, not when the person i'm cursing for subjecting me to the experience is myself... If the UI ends up anything less than instantly responsive, it'll be because i'm doing something wicked in the actual UI itself - not because it's waiting on a query.
----
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 dont know what you are doing, and I dont know where your project will end up. I dont know the SDLC of your project. So, I vote 1,3 and 5 until I know. I dare say most people will say, "Choose 1, cause I dont like 5" or "Choose 3 because I think it works better than 1". No one can take a quick vote on what you are doing, until one has a clear understanding of what you are doing and what you are trying to achieve. You say a small system, but will it grow? You want to do the UI stuff, but will you depend heavily on middleware and back end to provide the data accurately? Will your UI be the sole provider to the back end? Will UI also provide the business logic? Is reuse important? ....the list goes on.
Yeah, i gave the brief description of what i'm doing as more of a "get to know you" sort of thing. It's a straw poll - do you like 'em or hate 'em based on your experience on smaller projects, not necessarily what you'd recommend for me and my little deal.
----
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
-
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.
>>Just don't expect to make friends with any DBAs after you start advocating for it I cannot disagree more. :-D. I have to learn more communication skill in order to persuade them. Currently I am comfortable trying Developer Express' Express Persistence Framework (XPO). Of course, there is a leaning curve, however, when I think about the code maintainability (even for small program), OOP-friendly, DB platform neutrality, etc... it is worth it. Now, even if I have to NOT to use an ORM, I will write my own simple "ORM" (to handle simple select and update) classes (eg: in a portable device programming where some ORM framework might be too overkill).
I like you, and I love programming more.