CODEWITHSUNDEEP
c#.netdependency-injectionninjectagile
PercivalMcGullicuddy
PercivalMcGullicuddy

Reputation: 5533

Learning principles of Dependency Injection, applicable in this situation?

I have been doing a lot of reading and tutorials on Dependency Injection via Ninject in the hopes of re-factoring one of my applications to be more flexible and scalable in the future. My web app is built on top of an API that gives me access to the back-end infrastructure.

Part of my technical debt that I'm trying to clear up is the repeated code that comes with every single API call that I have to make. The API has about 45-50 methods for fetching and managing different entities.

The following (greatly simplified) code example illustrates a recurring pattern that is found everywhere in my code. Can Ninject/DI help make things easier for me?

namespace MyApp
{
public class example
{
    public  static WebAccount Fetch_Account(Guid accountID)
    {
        //Create instance of API, request and response objects
        WebAPI api = new WebAPI();
        Fetch_Account_Request accountRequest = new Fetch_Account_Request();
        Fetch_Account_Response accountResponse = new Fetch_Account_Response();

        //Api call security signature
        ApiSecuritySignature signature = new ApiSecuritySignature(/*My API ID */, /*My API Key */);

        accountRequest.API_ID = /* My API ID */;
        accountRequest.Token = signature.Token;
        accountRequest.TimeStamp = signature.Date;

        //Id of the account to be fetched
        accountRequest.Account_ID = accountID;

        //Fetch the account
        accountResponse = api.Fetch_Account(accountRequest);

        return accountResponse.Account;
    }


    public static void Manage_Account(WebAccount account)
    {
        //Create instance of API, request and response objects
        WebAPI api = new WebAPI();
        Manage_Account_Request manageAccountRequest = new Manage_Account_Request();
        Manage_Account_Response manageAccountResponse = new Manage_Account_Response();


        //Api call security signature
        ApiSecuritySignature signature = new ApiSecuritySignature(/*My API ID */, /*My API Key */);

        manageAccountRequest.API_ID = /* My API ID */;
        manageAccountRequest.Token = signature.Token;
        manageAccountRequest.TimeStamp = signature.Date;

        //account to modify
        manageAccountRequest.Account_ID = account.Account_ID;

        //set Account properties
        manageAccountRequest.Email =  account.Email;
        manageAccountRequest.Address_1 =  account.Address_1;
        manageAccountRequest.City = account.Postal_Zip;
        manageAccountRequest.Postal_Zip = account.Postal_Zip;
        manageAccountRequest.Country = account.Country;
        manageAccountRequest.State = account.State;

        //Make the call
        manageAccountResponse = api.Manage_Account(manageAccountRequest);
    }
}
}

It should be noted that I do not have access to the code for all of the request and response objects, they are part of a shared library that I reference.

Upvotes: 1

Views: 256

Answers (2)

jgauffin
jgauffin

Reputation: 101150

Dependency injection per se wont help you. It's job is just to make sure that the dependencies gets supplied (instead of letting the class itself create them).

An IoC container just takes care of when objects should be created and disposed i.e. the object lifetimes. (dependency injection is a bonus that you get)

The proper solution for you is to use the factory method pattern.

You can create an interface like:

public interface IWebApiFactory
{
    Fetch_Account_Request CreateAccountRequest();
}

so that you're code can be simplied to:

public  static WebAccount Fetch_Account(Guid accountID)
{
    var request = _factory.CreateAccountRequest();
    request.Account_ID = accountID;
    var response = api.Fetch_Account(accountRequest);
    return accountResponse.Account;
}

Then you can of course inject the IWebApiFactory class into the example class.

A side note: If you are using DI/IoC you should avoid static classes as much as you can.

You might be interested in reading my IoC articles (to understand IoC/DI better):

Upvotes: 3

Felice Pollano
Felice Pollano

Reputation: 33252

Yes you can create a factory in order to create class of type examples. Try to respect the Composition Root pattern by having that dependencies declared in a single place. You apparently need a lot of Managerxxx classes. You can just declare them being a contructor parametrs of 'example' class and ninject will create them with the possibly recursive dependencies.

Upvotes: 2

Related Questions