. Net – mixed stored procedure business logic and orm

The company I work for has developed a large application based almost entirely on stored procedures

We use classic ASP and SQL server, and the main part of business logic is contained in these stored procedures

For example, (I know, this is terrible...) a single stored procedure can be used for different purposes (insert, update, delete, perform some calculations...) In most cases, stored procedures are used for operations on related tables, but this is not always the case

We plan to turn to ASP in the near future NET(WebForms).

I have read many posts on stackoverflow, suggesting that I move business logic out of the database The problem is, I'm trying to convince those who make decisions in our company. I can't change their minds

Because I want to be able to use the advantages of object - oriented programming, I want to map tables to actual classes So far, my solution is to use ORM (Entity Framework 4 or NHibernate) to avoid manually mapping objects (mainly to retrieve data) and use some data access layer to call existing stored procedures (for saving)

I want your advice Do you think this is a good solution? Any ideas?

Editor: should I use the standard datatable / DataRow method?

Solution

in my opinion

Stored procedures are your friends for many reasons I enforce all database operations in stored procedures in my project, lock the application account on the SQL server, and only allow it to execute stored procedures (without any type of direct table access) Nevertheless, it is not good for me to mix update / delete operations in the same proc (although I prefer to combine insert / update in the same process)

Also note: when you migrate from ASP to ASP Net, any logic in the stored procedure does not have to be re implemented because it exists outside the web code Keep the 100 points that belong to them

The common "wisdom" these days suggests that you should only use your database server as object storage, which I strongly object to I have several projects that, after years of service, suddenly need to share data and logic with other applications written in different languages Most DB code is actually stored in the database and outside the application code, which makes code duplication between projects very simple and minimal

Mixing ORM with stored procedures sounds like a good way to lose weight and hair when you're young

Switch existing applications from the current data model to ORM, in addition to migrating from ASP to ASP Net MVC adds many variables and failure points to the already challenging tasks If you can't make a convincing argument to power that ORM is a good idea, you may ask yourself why