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.

Who is Participating?
ToddBeaulieuConnect With a Mentor Commented:
Hi. I haven't use EF, but I've worked with basic MVVM patterns.

My initial thought here is that I would never want a person object to have ACTIONS. It should just be a data store with attributes.

I'd use a View Model that knows how to perform category-specific actions against domain objects.

As for sprocs, my biggest concern for integrating complex business logic in them that affects other domain objects (that could already be loaded by the app) is how to get those "side effects" back into the app. How does the app know which objects need to be reloaded? For instance, if you remove a manager via a sproc, how do you tell the app to reassign the ten people under that manager to a different manager?

I generally prefer to do that in the VM. As it performs complex operations, it knows which DMs are affected and can update them directly. In fact, it can call related VMs to dole out outside, but related operations, allowing for better separation.

Of course, there are countless approaches, and you really need to experiment. You'll probably tweak your approach on each new major project, based lessons learned. I have a long list of what worked and what didn't from my last major project that will influence the next one.
MRSAuthor Commented:
The at the core, an “action” would really just be a grouping of database changes.  Nothing more.  

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…
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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.