Entity Framework: Stored Procedures vs. Partial Classes
Posted on 2010-08-31
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.