设计模式：使用IoC设置控制器，服务，存储库和UnitOfWork

Question

Imagine I have a service for car rental shop.

I have CarsController accepting ICarService in its only constructor, CarService accepting IUnitOfWork in its only constructor. IUnitOfWork has 3 singleton read-only properties for ICarsRepository, IUsersRepository and ILogsRepository and a Commit method. Dependencies are being resolved via any decent dependency injection container (ninject, unity etc) and EF is the underlying ORM.

I use this kind of architecture in almost all of my applications. And every now and then I come across a challenge:

In my CarsController there is a method called RentCar(int carId, int userId) . CarsController calls RentCar(int carId, int userId) on CarsService. CarsService needs to perform some business logic before and after calling CarRepository methods. This 'some business logic' could be for example verifying the user is valid, and saving some logs. As my IUnitOfWork gives me access to IUsersRepository and ILogsRepository I can interact with all repositories very easily and call commit on IUnitOfWork in the end when I am done.

However, the code that I will write to get the user and then validate it and log the event in DB, might already be there in IUserSerive and ILogsService. At this point I feel like I should be using those services within CarsService to avoid any duplication of logic.

Questions:

Is it a good idea to access other services from within a service? If Yes:

Should all dependent services be passed into the service via constructor individually, or is there a pattern like UnitOfWork, where all service can be accessed via read-only singleton properties?

All service methods call Commit on IUnitOfWork in the end. So If I do access the service within a service, I might call Commit before my original calling service has finished its work.

If I should NOT be calling services within a service, then what about the duplication of logic scenario above?

Answer 1

What you are describing here is the use of cross-cutting concerns. Validation, authorization and logging are no business concerns, they care cross-cutting concerns. So you don't want to pollute your business layer while adding this, and you want to prevent having to do lots of code duplication all over the place.

The solution to this problem is to move the cross-cutting concerns to decorators and apply them to your business logic services. Problem now of course is that you don't want to have to define a decorator per service, since that would again lead to a lot of code duplication.

So the solution to that is to move to the command/handler pattern . In other words, define a single generic abstractions for any business transaction in the system, for instance:

public interface ICommandHandler<TCommand>
{
    void Handle(TCommand command);
}

And define a 'command' DTO/message object per operation, for instance:

public class RentCarCommand
{
    public int CarId { get; set; }
    public int UserId { get; set; }
}

For each command you need to write a specific ICommandHandler<T> implementation. For instance:

public class RentCarCommandHandler : ICommandHandler<RentCarCommand>
{
    private readonly IUnitOfWork uow;

    public RentCarCommandHandler(IUnitOfWork uow) 
    {
        this.uow = uow;
    }

    public void Handle(RentCarCommand command)
    {
        // Business logic of your old CarsService.RentCar method here.
    }
}

This RentCarCommandHandler replaces the CarsService.RentCar method. If CarsService has multiple methods, for each method there will be 1 command + 1 command handler.

Now your controller can depend on ICommandHandler<RentCarCommand> instead of ICarsService :

public class CarsController : Controller
{
    private readonly ICommandHandler<RentCarCommand> rentCarHandler;

    public CarsController(ICommandHandler<RentCarCommand> rentCarHandler) 
    {
        this.rentCarHandler = rentCarHandler;
    }

    public ActionResult Index(int carId, int userId)
    {
        if (this.ModelState.IsValid) 
        {
            var command = new RentCarCommand { CarId = carId, UserId = userId };
            this.rentCarHandler.Handle(command);
        }

        // etc.
    }
}

By now you might be starting to think why we need all this extra 'complexity', but I would argue that we lowered the amount of complexity of the system, since we now only have one single abstraction ICommandHandler<T> left. Furthermore, think about the problem of adding cross-cutting concerns. That is now completely gone, since we can create decorators for that cross-cutting concerns such as validation:

public class ValidationCommandHandlerDecorator<TCommand> : ICommandHandler<TCommand> 
{
    private readonly IValidator validator;
    private readonly ICommandHandler<TCommand> handler;

    public ValidationCommandHandlerDecorator(IValidator validator, 
        ICommandHandler<TCommand> handler)
    {
        this.validator = validator;
        this.handler = handler;
    }

    void ICommandHandler<TCommand>.Handle(TCommand command) 
    {
        // validate the supplied command (throws when invalid).
        this.validator.ValidateObject(command);

        // forward the (valid) command to the real
        // command handler.
        this.handler.Handle(command);
    }
}

Now you can apply DataAnnotation's attributes to command properties and this validator will ensure that any command is verified.

Or some decorator that does some audit trailing:

public class AuditTrailingCommandHandlerDecorator<TCommand>: ICommandHandler<TCommand> 
{
    private readonly IAuditTrailRepository repository;
    private readonly ICommandHandler<TCommand> handler;

    public LoggingCommandHandlerDecorator(
        IAuditTrailRepository repository, 
        ICommandHandler<TCommand> handler) 
    {
        this.logger = logger;
        this.handler = handler;
    }

    void ICommandHandler<TCommand>.Handle(TCommand command) 
    {
        string json = JsonConverter.Serialize(command);
        this.repository.AppendToTrail(typeof(TCommand), json);

        this.handler.Handle(command);
    }
}

Since commands are simple data packages we an now serialize them to JSON and that will usually be enough for audit trailing. You can of course do exactly the same with logging.

And you can decorate your RentCarCommandHandler as follows:

ICommandHandler<RentCarCommand> handler = 
    new AuditTrailingCommandHandlerDecorator<RentCarCommand>(
        new AuditTrailRepository(uow),
            new ValidationCommandHandlerDecorator<RentCarCommand>(
                new Validator(),
                RentCarCommandHandler(uow)));

It would become quite cumbersome of course to apply this manually to each command handler in your system, but this is where DI libraries can come in handy. How to do this depends on the library you use.