standards-c-sharp

Service design

Interfaces

• Only create an interface if:
  • multiple implementations exist in application code, or
  • the component needs to be mocked for testability.

Unnecessary interfaces pollute the codebase and make it more difficult to understand.

Injection and mocking

• A component only needs to be mocked if it is impure, ie:
  • it has a side effect such as performing IO (eg. reading from disk, making a network call), or
  • it is non-deterministic - that is, it may return different results when called repeatedly with the same inputs (eg. DateTime.Now).
• An impure component will almost certainly need to mocked for unit testing. Therefore, it should be injected into its dependendants.

Static methods

• A pure function operates in-memory and doesn’t depend on external resources such as network calls, reading from hard disk etc. It therefore doesn’t need to be mocked, swapped out, or injected. Create such functions as static.
• If something can be static, then it probably should be.
• If a component has both static and instance methods, then consider moving the static methods into their own helper class.
• More on static methods vs instance methods.

Dependencies

• Keep each component’s dependency count to a reasonable level. The more dependencies, the more difficult the code is to change. An absolute maximum is 10, and a more reasonable level is 7 or fewer. See Avoid constructor over injection for more.
• Inject only impure components as dependencies (see above). This helps reduce the dependency count, and Keeps It Simple.
• A high dependency count is a good indication that a component should be refactored into more narrowly focused responsibilities.
• Declare a component’s dependencies explicitly in its constructor. Don’t use property injection. It’s super lame.
• Each injectable component should expose only a single public constructor. Multiple constructors lead to a fragile design and present maintainability issues. Use the null object pattern for truly optional dependencies.
• Prefer attribute based registration over explicit registration - eg. decorate your class with [RegisterSingleton] rather than registering directly with the container.
• Do not use DependencyResolver.Current. Inject your dependency through the constructor. Read more.

Example

Say we have a model that needs to be mapped to a view model:

public class MyModel
{
    public int Id { get; set; }
}

public class MyViewModel
{
    public int ModelId { get; set; }
}

Don’t

// so interface, much dependencies...

interface IViewModelMapper<TFrom, TTo>
{
    TTo Map(TFrom from);
}

public class MyViewModelMapper : IViewModelMapper<MyModel, MyViewModel>
{
    public MyViewModel Map(MyModel model)
    {
        return new MyViewModel
        {
            ModelId = model.Id
        };
    }
}

public class MyController
{
    private MyViewModelMapper mapper;
    private IMyService service;
    
    public MyService(MyViewModelMapper mapper, IMyService service)
    {
        this.mapper = mapper;
        this.service = service;
    }
    
    public MyViewModel Get()
    {
        var model = service.GetModel();
        var viewModel = mapper.Map(model);
        return Json(viewModel);
    }

Do

// KISS

public class MyViewModel
{
    public int Id { get; set; }

    // Method is pure, so doesn't need to be mocked or injected -> make it static:
    public static MyViewModel From(MyModel model)
    {
        return new MyViewModel
        {
            ModelId = model.Id
        };
    }      
}

public class MyController : ApiController
{
    private IMyService service;
    
    // We removed an unnecessarily injected dependency!
    public MyService(IMyService service)
    {
        this.service = service;
    }
    
    public MyViewModel Get()
    {
        var model = service.GetModel();
        var viewModel = MyViewModel.From(model);
        return Json(viewModel);
    }
}

This site is open source. Improve this page.