|
Definitely not
I don't know what it is
It's not applicable to my work
|
|
|
|
|
I don't use .NET, what should I answer? Not applicable, No idea what it is, or Definitely not? 
|
|
|
|
|
I don't use .NET either, so I didn't know what it was to even choose I don't use .NET. So, I chose I don't know what it is.  It does sound like a buzzword framework though. Maybe I'll write one called the Hype Framework and see if it catches on.
|
|
|
|
|
The client I've been working for uses Linq2SQL. Since it appears to have been slated for a slow painful execution by lack of support, I imagine we might eventually move to EF. The client really likes ORM so if L2S stops meeting their needs we'll move to it. But after looking at the SQL generated by both L2S and EF I don't believe it is performant enough out of the box. And the amount of code required to squeeze good performance out of the SQL doesn't save me any time or code beyond auto-generating my own data access code using CodeSmith or some other templating tool. I would look at it again if there were vendor specific providers (Sql, Oracle) instead of only ANSI SQL. If I could use those providers via an interface (or if they could be swapped out via configuration), then it might be good for small to mid size projects. I don't ever plan on using it for any significant size projects.
|
|
|
|
|
And I cannot fault them to that aspect. However, many of their technologies are used to make it easier and easier to develop applications fast but critically tied to a rapidly changing set of core technologies. Writing your own code, instead of using EF, is trivially easy for any developer worth his or her salt, however, I am finding a growing number of cannot be bothereds. In their mind, having an app 80% complete in 3 months and then spending 3 years doing the last 20% is acceptable. To me it is not.
I would rather author solid, maintainable, and efficient code based on the need as required and spend the extra month or two in initial development instead of the long years after trying to make something work that was cobbled together using a poorly controlled development approach.
Remember, kids, the primary selling point for EF is that if the Database constantly changes you will be able to update your code quicker. If the database constantly changes, you have poor change control management and your project is destined to fail. Writing an application on a changing db is an impossibility for anything more complicated than a simple DE/Tracking Appp.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Writing your own code, instead of using EF, is trivially easy for any developer worth his or her salt
Really? A developer 'worth his or her salt' would never state such a thing. 
Ennis Ray Lynch, Jr. wrote: Remember, kids, the primary selling point for EF is that if the Database constantly changes you will be able to update your code quicker.
But that is NOT the main purpose of an O/R mapper, dear kid.
Rather you use such a mapper for keeping the persistence related stuff away from your business model.
Ennis Ray Lynch, Jr. wrote: If the database constantly changes, you have poor change control management
Not always. There are many software products that are designed to fit in variable IT infrastructures. It's not 'poor change control management', it's a necessary feature.
Ennis Ray Lynch, Jr. wrote: Writing an application on a changing db is an impossibility for anything more complicated than a simple DE/Tracking Appp.
It's far from impossible for a 'developer worth his or her salt'. It's a common use case.
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: It's far from impossible for a 'developer worth his or her salt'. It's a common use case.
Of course it is a common use case and it is a major problem. Many projects are unnecessarily delayed years because of this with an ever increasing number of devs in a valiant effort to save a project that was doomed from the start.
Thomas Weller wrote: ut that is NOT the main purpose of an O/R mapper, dear kid.
Rather you use such a mapper for keeping the persistence related stuff away from your business model.
Next time you write an application that doesn't need to be changed when the underlying data model is radically altered let me know.
Thomas Weller wrote: Really? A developer 'worth his or her salt' would never state such a thing.
I did write such a thing.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: an application that doesn't need to be changed when the underlying data model is radically altered
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.
Ennis Ray Lynch, Jr. wrote: Many projects are unnecessarily delayed years because of this
This sounds like a case study for poor software design. But this is far from destiny - it is simply poor craftsmanship... 
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: 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
