Инъекция зависимостей уровня сервиса

Question

Я создаю веб-API, который будет называть сервисный уровень, и я пытаюсь изучить Dependency Injection (я надеюсь использовать ninject), но я не уверен, как создать зависимость от службы слой.

Это то, что позвонил веб-ави.

Вот вопросы, при вызове IPersonService, человек будет иметь пол определен, то он будет иметь имя, роль и этническую принадлежность. Я использую инсталляцию конструктора и не уверен, следует ли мне вызвать службу GenderService или я должен называть бизнес-уровень (в данном случае определяемый Core).

Должен ли я называть услугу, как на картинке выше, или ниже

Это то, что мой служащему выглядеть

namespace Service.Services 
{ 
    public class PersonService : IPersonService 
    { 
     private IPersonCore personCore = null; 
     private INameService nameService = null; 
     private IRoleService roleService = null; 
     private IGenderService genderService = null; 
     private IEthnicityService ethnicityService = null; 
     private IPrefixService prefixService = null; 
     private Person currUser; 

     public PersonService(IPersonCore _personcore, INameService _namecore, IRoleService _roleservice, IGenderService _genderservice, IEthnicityService _ethnicityservice, IPrefixService _prefixservice) 
     { 
      this.personCore = _personcore; 
      this.nameService = _namecore; 
      this.roleService = _roleservice; 
      this.genderService = _genderservice; 
      this.ethnicityService = _ethnicityservice; 
      this.prefixService = _prefixservice; 
     } 

     public IEnumerable<Person> GetAllPerson() 
     { 
      if (isAuthorized()) 
      { 
       return this.personCore.GetPersons(); 
      } 
      return null; 
     } 

     public Person GetPersonByID(int id) 
     { 
      if (isAuthorized()) 
      { 
       return this.personCore.GetPersonByID(id); 
      } 
      return null; 
     } 

     public Person GetPersonByEmail(string email) 
     { 
      if (isAuthorized()) 
      { 
       return this.personCore.GetPersonByEmail(email); 
      } 
      return null; 
     } 

     public IEnumerable<Person> GetPersonByName(string first, string last, string middle) 
     { 
      if(isAuthorized()) 
      { 
       Name newname = this.nameService.CreateName(first, last, middle); 
       return this.personCore.GetPersonByName(newname); 
      } 
      return null; 
     } 

     public IEnumerable<Person> GetPersonWithRoles(IEnumerable<Roles> r) 
     { 
     } 

     public IEnumerable<Person> GetPersonWithDOB(DateTime d) 
     { 
      if (isAuthorized()) 
      { 
       return this.personCore.GetPersonWithDOB(d); 
      } 
      return null; 
     } 

     public Person SetPersonRole(int id, Roles r) 
     { 
     } 

     public Person SetGender(int id, Gender g) 
     { 
     } 

     public Person SetEthnicity(int id, Ethnicity e) 
     { 
     } 

     public Person SetPrefix(int id, Prefix p) 
     { 
     } 

     public Person CreatePerson(Person p) 
     { 
      if (isAuthorized()) 
      { 
       return personCore.AddPerson(p); 
      } 
      return null; 
     } 

     public Person UpdatePerson(Person p) 
     { 
      if (isAuthorized()) 
      { 
       return personCore.UpdatePerson(p); 
      } 
      return null; 
     } 

     public Person ActivatePerson(int id) 
     { 
      if (isAuthorized()) 
      { 
       return personCore.ActivatePerson(id); 
      } 
      return null; 
     } 

     public Person DeactivatePerson(int id) 
     { 
      if (isAuthorized()) 
      { 
       return personCore.DeactivatePerson(id); 
      } 
      return null; 
     } 

     public bool DeletePerson(int id) 
     { 
      if (isAuthorized()) 
      { 
       return personCore.DeletePerson(id); 
      } 
      return false; 
     } 

     protected bool isAuthorized() 
     { 
      //Probably move to common 
      return true; 
     } 
    } 
} 

При вызове из Веб-API, мой вопрос с ним, является его звуком, как много зависимости от поиска чего-то определенного человека.

Answer 1

Вы можете упростить этот 2-мя способами:

1. Ваш PersonService не выглядит зависеть себя от роли, пола, этнического происхождения и Префиксами услуг, как вы не вызываете их из его методов. Это скорее оболочка, которую ваш клиентский код вызывает вместо прямого вызова этих служб. Если это так, то вы можете упростить PersonService, получая эти 4 зависимостей из:

   private IRoleService roleService = null; 
   private IGenderService genderService = null; 
   private IEthnicityService ethnicityService = null; 
   private IPrefixService prefixService = null; 
   

   И все эти средства в свои услуги:

   public Person SetPersonRole(int id, Roles r) 
   { 
   } 
   public Person SetGender(int id, Gender g) 
   { 
   } 
   public Person SetEthnicity(int id, Ethnicity e) 
   { 
   } 
   public Person SetPrefix(int id, Prefix p) 
   { 
   } 
   

2. Если вам необходимо абсолютно держать эти методов внутри вашего IPersonService, тогда вы будете вводить зависимости в методах, а не в конструктор.

   Что касается зависимости от Сервиса или Ядру, это зависит от того, что делает ваша служба. Если ваша служба просто вызывает ядро, тогда идите в Core. Если ваша служба выполняет какую-либо проверку или что-то еще, вы можете захотеть зависеть от нее, чтобы избежать копирования того же кода в PersonService.

Answer 2

Класс PersonService содержит много зависимостей, потому что вы нарушаете Single Responsibility Principle. У этого класса много обязанностей, и вы в конечном итоге меняете этот класс каждый раз, когда добавляете новую функцию (что является нарушением Open/Closed Principle). Кроме того, метод isAuthorized является сквозной проблемой, о которой этот класс не должен иметь понятия.

Кроме того, вы вставляете текущего зарегистрированного пользователя в PersonService. Это данные времени выполнения и constructing application components using runtime data is an anti-pattern.

Существует много способов исправить это, но все сводится к пониманию принципов SOLID. Однако это может быть сложной задачей, особенно если вы только начинаете с разработки DI и программного обеспечения. Есть много книг, которые вы можете прочитать об этом, например, the amazing work от Роберта К. Мартина и книги об инъекции зависимостей, такие как Mark Seemann's Dependency Injection in .NET.

Дизайн, который очень помог мне в последние годы, - это архитектуры, основанные на сообщениях, где варианты использования описываются сообщениями, а реализации описываются общими абстракциями (см. this и this). Эти конструкции оказались очень гибкими и удобными в обслуживании, поскольку они позволяют прозрачно передавать сквозные проблемы и позволяют добавлять новые функции без изменения существующего кода. Такой дизайн также позволяет снизить уровень веб-API до простой части инфраструктуры, которая не требует изменения при добавлении новых функций. Вы можете прочитать об этой концепции here (обратите внимание: эта статья посвящена WCF, но концепция для веб-API одинакова), а here - это репозиторий Github, который показывает, как реализовать это как в WCF, так и в Web API.

Желаю вам удачи в вашем стремлении к освоению программного обеспечения.