|
Thomas Weller wrote: O/R mapping is not about decoupling the database data model from the business model. They have to be kept in sync anyway. It's about keeping the technical things away from the business layer
Nah, you can write a perfectly separate ADO.NET layer to decouple the database specifics from the business objects, and probably even better because many OR-mappers require you to litter your data objects with all kinds of attributes. OR-mappers just saves the programmer some typing (if he's lucky) at the cost of added complexity, restrictions and worse performance.
Wout
|
|
|
|
|
I'm afraid I don't get your point.
I don't think O/R mapping is the holy grail or something - I don't even think it's the best choice in all situations. It indeed adds complexity to a project.
What I'm trying to say is: With an ORM you have a standardized way to keep DBMS-specific stuff away from your business logic. And this can be very important when it comes to maintenance or if you're building a system that has to be DBMS-agnostic. So in some cases, even 1 or 2 additional months of development may be well worth the effort.
wout de zeeuw wrote: OR-mappers just saves the programmer some typing (if he's lucky) at the cost of added complexity, restrictions and worse performance.
I don't see anything in this statement that I would not agree with. But it does not tell the whole story. And performance issues are greatly overestimated in my view. In my experience they almost never play a role in real-life business software.
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: kids
Probably what EF is aimed at, a well put point may I add.
|
|
|
|
|
Norm .net wrote: a well put point may I add
Not at all, my kid. Object-relational mapping (which EF is one of, but by far not the best and by far not the first) is an advanced software architecture methodology. For people who are sick of all this vendor-specific DBMS details that may even change between different versions of the same product. It's for adults only!
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Thomas Weller wrote: Not at all, my kid. Object-relational mapping (which EF is one of, but by far not the best and by far not the first) is an advanced software architecture methodology. For people who are sick of all this vendor-specific DBMS details that may even change between different versions of the same product. It's for adults only!
Yes your are entitled to your own opinions, put take a tip from somebody who has been in software development for over 20 years, try not to be condescending when replying to posts - pal
|
|
|
|
|
Norm .net wrote: try not to be condescending
Ok, sorry for that. One really should focus on real technical issues only. But the same applies to you and Ennis Ray Lynch, Jr.: you called people who prefer to use an ORM over plain SQL kids - and this greatly disrespects people who have not the same technical opinion as you. (And they also got this opinion from years of practical experience..)
But let's not start a flame war on that - let's just say there are good reasons for both positions.
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
|
I'm a passionate VS user and C# developer. I'm not at all one of these Microsoft is evil nerds.
But - as very much that I am doing in my everyday work is already built on Microsoft products - I avoid using them when there are suitable alternatives. Doing everything the way it was intended by one companies think tank always comes out very bad - at least in the long run. (Hello to all VB6 and LinqToSql users...  )
For me it's just a matter of keeping my toolbox healthy. I don't want to become subject to the politics of one single company. These politics are aimed to increase profit, not to increase a developers welfare...
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
What libraries and patterns do you use then? All your own from scratch?
|
|
|
|
|
Paul Watson wrote: What libraries and patterns do you use then?
For large-scale projects I use a combination of DDD-style business objects and NHibernate (or some other O/R mapper if the customer insists...) that does the persistence stuff. For smaller projects I might indeed consider writing the database stuff from scratch.
That's the point: We have NHibernate - which is well designed and well supported, albeit on the edge of being overly complex. So what do we need EF for if it's not just another MS-RTW attempt (MS-RTW: re-inventing the wheel, but this time with an MS label stuck upon it...  )?
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
I've only done a preliminary comparative research and it looks like EF combined with VS 2008 gives you visual development tools unlike nHibernate.
|
|
|
|
|
vlad97 wrote: looks like EF combined with VS 2008 gives you visual development tools unlike nHibernate
Maybe. I did not explore EF in-depth, because I won't use it anyway. NHibernate admittedly is much more complex to learn and it may be overkill for many projects, but I already am familiar with it.
To be explicit about that: I am not saying: Don't use EF. Use NHibernate instead. I can't say this because I don't know much about EF except that it's MS's version of an O/R mapper. I'm just saying that I won't add it to my personal toolbox for the reasons outlined above.
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
modified on Monday, November 10, 2008 10:26 AM
|
|
|
|
|
Thomas Weller wrote: So what do we need EF for if it's not just another MS-RTW attempt (MS-RTW: re-inventing the wheel, but this time with an MS label stuck upon it... Roll eyes )?
I have heard from Microsoft that a key motivation for doing their own thing is that they have customers who won't use non-MS originated technology, i.e., won't look at any important technique until MS provides a solution for them. I have certainly worked at places where they are suspicious of open source, even of such trivial things as the PowerCollections lbrary.
Kevin
|
|
|
|
|
Kevin McFarlane wrote: they have customers who won't use non-MS originated technology
Ah I see. This is a perfectly valid business strategy that makes sense.
But someone should tell these customers that MS is not the holy grail of software development but just a company who does not care too much about their customers if it pays for them otherwise...
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
I had a go at it when 3.5 SP1 came out. It has nice features but it is not ready for production work. For example it has bugs when you try to change an existing design you have made and just refuses to change it, so many times I had to delete the whole design and start again. This was OK in the small project I've tried it but completely unacceptable for a bigger project. I will wait before using it in a bigger/production level project, probably when its next version comes out I will try again.
|
|
|
|
|
I have to concur. I have been looking for a ORM suitable for winforms. I took a look at EF and decided that it complete enough for use. There are also many more mature ORM frameworks available, nHibernate being one of the more popular ones. The link below lists some of the limitations of EF:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2623082&SiteID=1
MS is continuing to develop the framework but do you really want to risk embracing a framework that could be abandoned in a couple of year for the next new thing?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
