Служебный слой действует как фасад для DAL? - PullRequest
1 голос
/ 03 февраля 2012

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

Но говорит ли теперь докладчик со служебным слоем? И «разрешено» ли ведущему доступ к репозиториям? Или все должно идти через сервисный слой? В последнем случае уровень обслуживания является просто посредником:

MyFooService:

public List<Foo> GetAllFoo()
{
   var listFoo = new FooRepository().GetAll().TiList();

   return listFoo;
}

Ведущий:

public List<Foo> GetAllFoo()
{
   var listFoo = new MyFooService().GetAllFoo();

   return listFoo;
} 

Это хороший путь? Или «разрешено», чтобы докладчик напрямую вызывал хранилище?

Ответы [ 2 ]

5 голосов
/ 03 февраля 2012

Иногда вам не нужно чрезмерно проектировать вещи или навязывать шаблоны, когда они вам не нужны.

DAL сам по себе является специальным сервисом для доступа к данным.

Как правило, ваш сервисный уровень будет делать вещи, не связанные напрямую с вашими данными. Подумайте о таких вещах, как PaymentService , AnalyticsService и т. Д. И т. П., Которые можно разделить на компонент многократного использования.

Допустим, вам нужно было поделиться сообщением со всеми социальными сетями, вы могли бы поместить это в службу, которая выполняет работу по входу в нужные социальные сети и публикации:

MySocialBlastService : ISocialService 
{
  void ShareToTwitter() {  }
  void ShareToFacebook(){ }
}

Теперь с вашего контроллера / докладчика вы можете позвонить в эту службу.

public ActionResult ShareLink(string link..) //asp.net-mvc method as an example
{// maybe you could use dependency injection here to get ISocialService
  ISocialService _service;
  _service.ShareToTwitter(link);
}

Точно так же вы понимаете, что такое бизнес-логика:

MathService
{
 int Add(a,b) { ..} //this is business logic
}

Это кое-что, что вам нужно сделать, и вы можете сделать это, не касаясь интерфейса, это нужно заключить в капсулу. Более реальными примерами являются SecurityService.ResetPassword()

Когда вы вызываете это из контроллера:

Вы можете использовать бизнес-логику добавления в веб-приложении или в приложении Windows и получать входные данные от пользователя через некоторый интерфейс. Как вы делаете это логика контроллера.

public ActionResult Calculate(int a, int b)//comes from webpage
{
 //this is controller logic
 int ret = MathService.Add(a,b);
 //logic to send ret back 
 //to some other page to display to user.
}
0 голосов
/ 03 февраля 2012

Я бы сказал, что если вы занимаетесь «серьезной» средне-крупномасштабной разработкой, лучше не вкладывать бизнес-логику в уровень презентации.Как вы изолируете это другой вопрос.

С другой стороны, если вы используете что-то вроде Entity Framework или NHibernate, я бы создавал репозитории, только если действительно необходимо абстрагировать доступ к данным, например, для использования имитаций при тестировании.

...