Mixing stored procedures and ORM
- by Jason
The company I work for develops a large application which is almost entirely based on stored procedures.
We use classic ASP and SQL Server and the major part of the business logic is contained inside those stored procedures.
For example, (I know, this is bad...) a single stored procedure can be used for different purposes (insert, update, delete, make some calculations, ...). Most of the time, a stored procedure is used for operations on related tables, but this is not always the case.
We are planning to move to ASP.NET in a near future.
I have read a lot of posts on StackOverflow recommending that I move the business logic outside the database.
The thing is, I have tried to convince the people who takes the decisions at our company and there is nothing I can do to change their mind.
Since I want to be able to use the advantages of object-oriented programming, I want to map the tables to actual classes.
So far, my solution is to use an ORM (Entity Framework 4 or nHibernate) to avoid mapping the objects manually (mostly to retrieve the data)
and use some kind of Data Access Layer to call the existing stored procedures (for saving).
I want your advice on this.
Do you think it is a good solution? Any ideas?
