If I have all my business logic in code and make use of Entity Framework, in what situations (if any) would I be better moving some business logic to a stored procedure, instead of keeping it all in code?To be clear, I mean in conjunction with the current setup (business logic in code), not instead of. I have seen a number of similar questions that are asking for the pros and cons of having all business logic in stored procedures, but I haven't found much regarding using stored procedures sparingly for edge case logic, while keeping the rest of the business logic in code.If it makes a difference, I am using MSSQL and Entity Framework.These are the situations where I have used stored procedures before:A complicated report that was taking minutes to run (this was a page in a web app). I found I could write SQL that was much more efficient (only taking seconds to run) than what LINQ was providing.A web application needed to read and write to a few tables on a separate database which contained a lot of other, sensitive information that was irrelevant to the application. Rather than giving it access to everything, I used a stored procedure that only does what is needed, and only returns limited information. The web application could then be given access to this stored procedure only, without access to any tables etc.Other posts I have looked at before asking this question:Stored Procedures a bad practice at one of worlds largest IT software consulting firms?Pros and Cons of holding all the business logic in stored procedures in web applicationhttps://stackoverflow.com/questions/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-codehttps://dba.stackexchange.com/questions/2450/what-are-the-arguments-against-or-for-putting-application-logic-in-the-database/2452#2452When not to use ORM and prefer stored procedures?
When should I use stored procedures?
design;sql server;orm;business logic;stored procedures
You have a couple of perfectly good scenarios already. There are lots of other reasons too.  EF is really good at CRUD and at pretty straight forward reporting.  Sometimes, though, EF is not the perfect tool.  Some other reasons (scenarios) to consider using stored procedures in combination with Entity Framework would include:You have complex units of work, perhaps involving many tables, that cannot be wrapped in a transaction easily using the features of EF.  Your database does not play well with EF because it fails to take advantage of declarative referential integrity (foreign key constraints).  This is usually a bad scenario to find yourself in, but there are sometimes appropriate scenarios, such as databases used for ETL processes.You need to work with data that crosses server boundaries with linked servers.You have very complex data retrieval scenarios where bare metal SQL is needed in order to ensure adequate performance.  For example, you have complex joins that need query hints to work well in your specific situation.Your application does not have full CRUD permissions on a table but your application can be allowed to run under a security context that your server trusts (application identity, rather than user identity, for example).  This may come up in situations where DBAs restrict table access to stored procs only because it gives them more granular control over who can do what.I'm sure there are many more besides these.  The way to determine the best path forward in any particular circumstance is to use some common sense and to focus on the primary goal, which should be to write high quality, easily maintainable code.  Pick the tool(s) that give you this result in each case.