Должен ли класс обслуживания объекта вызывать сервис другого объекта или его хранилище

Question

Я работаю над веб-приложением ASP.Net MVC 3 (EF 4.1), разделенным по слоям: модели, репозитории, службы, контроллеры, ViewModels в некоторых случаях и представления.лучшей практики.Должен ли класс обслуживания объекта, которому требуется доступ к другому объекту, использовать свой сервис или свой репозиторий.Например, скажем, что сервисному методу для объекта A необходимо обновить объект B при создании A.Должен ли класс обслуживания A использовать хранилище B или уровень обслуживания?И то и другое возможно, но какова лучшая практика?Лично я бы предпочел услугу для доступа к другой услуге.Таким образом, это, так сказать, доступ к более развитым методам.

Answer 1

Я бы предпочел звонить между классами обслуживания, потому что вам может потребоваться также некоторая бизнес-логика из другого сервиса.Но будьте осторожны, чтобы избежать циклических зависимостей.Я рекомендую вам использовать внедрение зависимостей, которое поможет вам избежать возможных циклических зависимостей.Также рассмотрите возможность создания интерфейсов для ваших классов обслуживания и использования этого интерфейса из ваших клиентских классов (передайте конкретную реализацию конструктору).

Тогда ваш SericesA будет выглядеть так:

class ServiceA : IServiceA
{
    public ResultA Method1() { //some logic };
    public void Method2() { //some logic };
}

ServiceB, которыйзависит от ServcieA.

class ServiceB: IServiceB
{
   private IServiceA _serviceA;
   public ServiceB(IServiceA serviceA)
   {
      _serviceA = serviceA;
   }

    public ResultB Method()
    {
         var result = _serviceA.Method1();
         // get result from service A and create and return result for service B
    }
}

Answer 2

Вы никогда не должны смешивать это. у вас есть объект / документ, для этого у вас должен быть специальный репозиторий, сервис, контроллер. Если вы хотите использовать что-либо определенное для этого документа где-либо, оно должно осуществляться через сервисный вызов, а не напрямую через репозиторий другого класса. Это не очень хорошая практика с точки зрения дизайна.

Answer 3

Я склонен прибегать к обычно используемым принципам и практикам для такого рода решений; СУХОЙ (не повторяйся сам) и КИСС (Держи это простым, глупый) могут быть применимы здесь.

Если вам не нужно было повторять некоторую логику в результате обхода класса обслуживания объекта B, я бы вызвал хранилище объекта B непосредственно из класса обслуживания объекта A.

Это небольшая деталь, но это означает, что задействован на один класс меньше (ServiceClassA> RepositoryClassB, а не ServiceClassA> ServiceClassB> RepositoryClassB), что делает его более простым решением, на мой взгляд.

НТН