Entity Framework: Stored Procedures vs. Partial Classes
So I have run into a design fork and I am trying to figure out which path is the best option. I am using the .NET entity framework as the backbone to an application that will contain a web frontend and a forms frontend. In order to keep the logic centralized I have created a middle tier project that contains the entity framework objects along with the additional business objects that I use in both the forms and web app.
I am at the point where I am need to start implementing logic beyond the basic reading and writing to database fields. For instance one of the objects in the database is a “Person”. You might take a logical action on that person that makes them a Manager. When you take that action, it not only updated the “person” object, but also various other objects.
So here is my dilemma. It seems like I can successfully implement this logic 2 ways.
1) Implement the complex logic directly in the database using stored procedures.
2) Extend the objects defined by the Entity Framework using Partial Classes.
Both of these seem like viable and workable solutions. The advantages from what I can tell so far is that using the partial class will let me take advantage of things like passing complex objects to routines and overloading routine. While the advantage of keeping the logic in Stored procedures would be that the logic is stored at a lower level should I ever need to make it available to an external application.
From what I can tell, neither approach is right or wrong, but as I am fairly new to the Entity Framework I wasn’t sure if there is something I was missing. I am open to any input people might have on which path is better and why.
Thanks in advance for taking the time.
I am at the point where I am need to start implementing logic beyond the basic reading and writing to database fields. For instance one of the objects in the database is a “Person”. You might take a logical action on that person that makes them a Manager. When you take that action, it not only updated the “person” object, but also various other objects.
So here is my dilemma. It seems like I can successfully implement this logic 2 ways.
1) Implement the complex logic directly in the database using stored procedures.
2) Extend the objects defined by the Entity Framework using Partial Classes.
Both of these seem like viable and workable solutions. The advantages from what I can tell so far is that using the partial class will let me take advantage of things like passing complex objects to routines and overloading routine. While the advantage of keeping the logic in Stored procedures would be that the logic is stored at a lower level should I ever need to make it available to an external application.
From what I can tell, neither approach is right or wrong, but as I am fairly new to the Entity Framework I wasn’t sure if there is something I was missing. I am open to any input people might have on which path is better and why.
Thanks in advance for taking the time.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Ah, the age old ... who's consuming the data question. If other applications are consuming, you're right, you might want to explore all your options. I've actually found that the vast majority of my apps over the years were pretty centralized so I could embed the business logic in the core app itself.
In a recent project, where some core logic was in the DB, I had a number of messy situations where the app needed to either re-query data that was updated by a sproc or even worse, duplicate the business logic of the DB on the domain objects! Ugly!
In one case, I had an LTS sproc return a number of output arguments so I could update the DM upon successful save.
It really got me thinking though, if you MUST do related updates in the DB, some mechanism to communicate back a list of DMs affected could be quite useful. The app would, of course, need to know how to handle that through some sort of specialized data loader. My head's hurting just thinking of the scenarios.
In a recent project, where some core logic was in the DB, I had a number of messy situations where the app needed to either re-query data that was updated by a sproc or even worse, duplicate the business logic of the DB on the domain objects! Ugly!
In one case, I had an LTS sproc return a number of output arguments so I could update the DM upon successful save.
It really got me thinking though, if you MUST do related updates in the DB, some mechanism to communicate back a list of DMs affected could be quite useful. The app would, of course, need to know how to handle that through some sort of specialized data loader. My head's hurting just thinking of the scenarios.
ASKER
I see your point on the on the “side effects”. I would probably make more sense to build my business logic onto the EF objects so whatever is changed is reflected in the objects in memory. If I ever did need to make the objects or “actions” available to another application I could just expose them via services/interfaces..
Thanks for taking the time…