EDN Admin
Well-known member
When I first put production code against a SQL database, I used a stored procedure data access strategy: in what I would later come to know as the data access layer, one stored procedure would equal one method. There were some simple CRUD abstractions I
would develop later, but generally speaking this is one bit in my preferred coding style that has remained essentially unchanged through my entire professional career.
This isnt to say that I wasnt exposed to other ways of doing things; I had the benefit of working in many different organizations since then, building large and small projects using a great variety of architectures. Of all the variation in data access
strategy Ive seen, Ive encountered basically only two other flavors that do not use stored procedures. One is ADO.NET control data binding that places generated SQL in compiled code, which I dont think is worth discussion. Everything else Ive seen is essentially
ORM.
I could write a lot about why I think this way, but Im just going to cut to the chase - regardless of framework, Ive come to believe that the idea of ORM itself is flawed. I dont say this because Ive used LINQ to SQL or the Entity Framework. No, thats
why Im posting here. I came to this conclusion using NHibernate. This is a "mature" ORM framework, and everyone Ive worked with directly eventually said things like "it takes me forever to do the simplest things", "doesnt handle design changes well, you
need unit tests on everything", "too slow", "too complicated", and "avoid at all costs". This experience was on a project that took 9 developers 6 months that by all rights should have been possible for one developer to complete in less than 3.
So I find myself still sticking with a DAL strategy I settled on in basically my first week of professional programming, back in 1998. The code that does this has changed, but the idea hasnt. Every year or so I feel a strong need to re-examine this decision,
especially when Im not forced to use something different.
Ive looked at the current versions LINQ to SQL and the Entity Framework, and Im tempted to damn them for the same reasons I damned NHibernate.
Those among you who have coded for a long time and worked with many different architectures, whats your preferred DAL strategy and why?
Paul
View the full article
would develop later, but generally speaking this is one bit in my preferred coding style that has remained essentially unchanged through my entire professional career.
This isnt to say that I wasnt exposed to other ways of doing things; I had the benefit of working in many different organizations since then, building large and small projects using a great variety of architectures. Of all the variation in data access
strategy Ive seen, Ive encountered basically only two other flavors that do not use stored procedures. One is ADO.NET control data binding that places generated SQL in compiled code, which I dont think is worth discussion. Everything else Ive seen is essentially
ORM.
I could write a lot about why I think this way, but Im just going to cut to the chase - regardless of framework, Ive come to believe that the idea of ORM itself is flawed. I dont say this because Ive used LINQ to SQL or the Entity Framework. No, thats
why Im posting here. I came to this conclusion using NHibernate. This is a "mature" ORM framework, and everyone Ive worked with directly eventually said things like "it takes me forever to do the simplest things", "doesnt handle design changes well, you
need unit tests on everything", "too slow", "too complicated", and "avoid at all costs". This experience was on a project that took 9 developers 6 months that by all rights should have been possible for one developer to complete in less than 3.
So I find myself still sticking with a DAL strategy I settled on in basically my first week of professional programming, back in 1998. The code that does this has changed, but the idea hasnt. Every year or so I feel a strong need to re-examine this decision,
especially when Im not forced to use something different.
Ive looked at the current versions LINQ to SQL and the Entity Framework, and Im tempted to damn them for the same reasons I damned NHibernate.
Those among you who have coded for a long time and worked with many different architectures, whats your preferred DAL strategy and why?
Paul
View the full article