|
Sorry, but this post is full of crap. You think SQL sucks because you prefer not having your business logic "smeared" over different places and in different languages. Surely you can see how this is apples and oranges and flawed logic right?
And, you can protect your DB if you don't like it being "smeared".
Regarding ORM, it has its flaws too. It makes the data store way too dependent on the application to work properly. While it's a nice concept, it's far from perfect.
|
|
|
|
|
Jeremy Falcon wrote: Sorry, but this post is full of crap.
It's not. It's just about something you don't agree with. You should choose your words more carefully.
Jeremy Falcon wrote: You think SQL sucks
I don't think so. SQL serves its purpose quite well. I just don't want to have pieces of SQL in the main part of my software. SQL is part of a DB which in turn is part of some persistence system that should help my business logic in doing whatever it's supposed to do. But SQL is not the software itself and thus should be kept apart from the functional pieces of the software - it clearly is an infrastructural service and nothing more. An ORM helps maintaining that separation and prevents you from reinventing the wheel (i.e. writing data access code for every single project) again and again.
Jeremy Falcon wrote: It makes the data store way too dependent on the application
If the data store does not depend on the application, what is it good for then anyway?
Jeremy Falcon wrote: While it's a nice concept, it's far from perfect.
As everything else out there in the wild. Sure, it has its flaws. I never stated and never believed it is perfect. It's not even the preferable solution for every single situation. But in general it's a good one.
Generally, an O/R mapper is not about 'hiding SQL'. You can use SQL freely inside the mapper. There might be people out there who believe that they can avoid learning SQL and use an O/R mapper instead - I'm not one of them.
An O/R mapper is just an advanced conceptional technique that moves data access one step further.
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 not. It's just about something you don't agree with. You should choose your words more carefully.
You're right, I don't agree with faulty logic.
Thomas Weller wrote: I don't think so. SQL serves its purpose quite well. I just don't want to have pieces of SQL in the main part of my software. SQL is part of a DB which in turn is part of some persistence system that should help my business logic in doing whatever it's supposed to do. But SQL is not the software itself and thus should be kept apart from the functional pieces of the software - it clearly is an infrastructural service and nothing more. An ORM helps maintaining that separation and prevents you from reinventing the wheel (i.e. writing data access code for every single project) again and again.
And no valid reasons outside of prejudice is mentioned.
Thomas Weller wrote: As everything else out there in the wild. Sure, it has its flaws. I never stated and never believed it is perfect. It's not even the preferable solution for every single situation. But in general it's a good one.
And it's still worse than SQL if you care about the design of your application being truly extensible.
Thomas Weller wrote: enerally, an O/R mapper is not about 'hiding SQL'. You can use SQL freely inside the mapper. There might be people out there who believe that they can avoid learning SQL and use an O/R mapper instead - I'm not one of them.
An O/R mapper is just an advanced conceptional technique that moves data access one step further.
But your code doesn't use it and therefore it's pointless to mention this since it's no longer quite as portable.
|
|
|
|
|
This post reads as if we are talking about two completely different things. I don't really get what you mean and it's apparent from your answers that you also don't really realize my points.
That's why I end this pointless discussion here.
Regards
Thomas
www.thomas-weller.de
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: you also don't really realize my points.
Sorry, but you assume too much. It's pretty straightforward, you say A sucks without giving a real reason why. You say B doesn't suck without giving a real reason why. I say prove A sucks; you don't. I give a disadvantage to B that you don't act as if its important. So, we go 'round and 'round.
|
|
|
|
|
Jeremy Falcon wrote: It's painful when it's abused. It is not painful for practical use
I agree. If there is anything in a query that begins to get too complex, then I usually treat that as an indicator that maybe that part of the database needs to be normalized better.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
True dat. 
|
|
|
|
|
Thomas Weller wrote: In my last project, we wrote an application that was designed to interact with any database whatsoever.
This would be very difficult to achieve but I don't see how a wrapper around SQL (e.g. ET) would solve the problem since the it is only being moved one layer down and it would still have to be solve there.
For multiple SQL server support I tend to use SQL localization. Each supported server type will have it's set of SQL queries. From previous experience, most of the SQL queries are exactly the same and only a few need to be reworked. This approx obviously does not give a solution for "any database whatsoever" but it is usually enough.
Regards.
|
|
|
|
|
PedroMC wrote: I don't see how a wrapper around SQL (e.g. ET) would solve the problem
It indeed does not solve the problem but it makes it much more manageable. Good O/R mappers like NHibernate (not EF!) have support for many DBMS systems. Basically it's just a matter of configuration (there are always some pitfalls, but they are not too painful).
PedroMC wrote: only being moved one layer down
Basically yes. But that's a great big lot for larger business apps!
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.
|
|
|
|
|
It's not about whether you use SQL or not, it's about whether you decouple the DAL from the rest of the app. Not that the EF helps you with that either, you can easily write code using the EF in the presentation layer!
Marc
|
|
|
|
|
Explicitly using SQL does not prevent decoupling/layering the data access so that is a non issue when comparing EF and explicit SQL usage.
With correct layering the DAL can internally use EF, explicit SQL, or something else to handle the data access.
Regards.
|
|
|
|
|
good call Marc. i am shocked that it took so many posts to get to this.
|
|
|
|
|
Bad pun alert....
When it comes to all these new technologies, I just say EF it. 
|
|
|
|
|
PedroMC wrote: SQL is not the best ever designed language
It's okay, there are worse languages designed.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
