How to use Dependency Injection when developing Stored Procedures? - stored-procedures

Question

In database Stored Procedures are often used to handle business logic. (There is a debate that where the logic should be, but it's not the topic here)
When more and more SP are written, the system becomes very complex. The main reason I think is the dependencies (SP1 depends on SP2, SP2 depends on SP3 ...)
In OO world, there is the Dependency Injection pattern and also many IoC containers (such as Spring) to solve the dependency problem.
In SP world, can this patten be applied? How? Any tools?

Answer 1

Dependency injection mostly makes sense in an environment that supports polymorphism: you have an interface which can have one of many implementations, and you offload the discovery of proper implementation to a certain framework.
In SQL, there is no distance between Stored Procedure interface and its implementation -- you define the interface with the procedure. It is hard to think of a case when you actually define multiple procedures as interchangeable within a common signature.
Practically speaking, for dependency injection you would also need some key to tell the system what is it that you want to have injected. In OOP languages, very often the interface is a key. But you probably do not want SP signature as a key. And if you look up procedure by name, then how is it different from just executing it directly?
There is a reason why OOP exists and why it is a popular way to manage complexity. Dependency injection builds upon its core concepts and does not seem to be well-applicable to procedural environment.

Answer 2

Although it's not recommended. There is a way to use Dependency Injection in a SQL environment (with stored procedures, functions, views, and even tables). It involves a lot of Dynamic SQL, Triggers, and gets very messy after a while. But, just for the sake of answering the question, here goes:
First, you have to decide what kind of dependency you are injecting, and how it is accessed. Let's say, for this example, it is a Company ID, and you want to execute different objects based on the company, while remaining agnostic in higher-level procedures and follow D.R.Y (don't-repeat-yourself).
So you need a way to store this company ID in a way that can always be retrievable regardless of where you are and what is passed in. You don't want to always have to pass in the Company ID to the SQL object, so you use CONTEXT_INFO. This is a value that is constant through a thread, and is unique to that thread.
SET #Context = CAST(15 AS VARBINARY(128))
SET CONTEXT_INFO #Context;
Now you can access the context like this:
SELECT #Context = CONTEXT_INFO();
SET #CompanyID = CAST(#Context AS INT)
Are you with me so far?
This is where it starts to get really messy.
Create a table for yourself with the names of the company-specific objects.
CREATE TABLE CompanyObjectRegistry (ObjectSchema VARCHAR(100), ObjectName VARCHAR(100), CompanyID)
Store your objects here:
INSERT CompanyObjectRegistry
VALUES ('CompanyFifteen', 'DoSomethingCool', 15),
('CompanyTwelve', 'DoSomethingCool', 12);
Then you create the top-level procedure:
CREATE PROCEDURE DoSomethingCool (#Data VARCHAR(10), #Param2 INT)
AS
DECLARE #CompanyID INT = CAST(CONTEXT_INFO() AS INT),
#SQL NVARCHAR(MAX) = '
EXEC [SCHEMA].DoSomethingCool ''' + #Data + ''', '
+ CAST(Param2 AS VARCHAR(10)) + ';'
SET
SELECT #SQL = REPLACE(#SQL, '[SCHEMA]', ObjectSchema)
FROM CompanyObjectRegistry
WHERE CompanyID = #CompanyID
EXEC(#SQL)
This has a small overhead because of the DSQL, and the fact that it can't be compiled. You can remove some of this overhead by using a "generate" procedure which generates this "base" procedure automatically from the contents of CompanyObjectRegistry and uses IF statements.
If you need to, you can have a trigger add to CompanyObjectRegistry and generate the base object when one of the underlying objects is edited/added. You would use a DDL trigger for this.
Here's how you would do this for tables:
DECLARE #TableName VARCHAR(100) = 'DoSomethingCool';
SET #SQL = 'CREATE VIEW ' + #TableName + ' AS '
+ (SELECT '
SELECT * FROM ' + ObjectSchema + '.' + ObjectName + '
WHERE ' + CAST(CompanyID AS VARCHAR(10)) + ' = #CompanyID
UNION ALL ' -- You would have to remove the last 10 characters from the result
FROM CompanyObjectRegistry
WHERE ObjectName = #TableName
FOR XML PATH(''), TYPE).value('.', 'nvarchar(max)')
EXEC (#SQL)
Views can be injected in the same way, just select * from each view.
Functions are very hard to do because you can't do either of the above approaches. You have to use the header of the function and generate the body.
It will take a lot of time. So if you have a choice... don't.