Взаимодействия между слоями сервиса, модели и репозитория - PullRequest
Новая
       0

Взаимодействия между слоями сервиса, модели и репозитория

2 голосов
/ 03 ноября 2011

Мне было поручено перевести приложение из SharePoint в .NET.Я заинтересован в том, чтобы сделать это правильно, поэтому я получил книгу по архитектуре, чтобы прочитать о шаблонах и практиках.

Я пытался смоделировать все с помощью доменного дизайна.У меня есть Модель, которая представляет мой мир, Репозиторий для хранения его в базе данных и Сервисный уровень для взаимодействия с пользовательским интерфейсом (который является WebForms, потому что у меня нет опыта работы с MVC, и я уже с трудом справляюсь с этой задачей).

Мне трудно понять, как слои взаимодействуют друг с другом.Я понимаю, что Модель должна быть основой всего.Он не ссылается ни на что, другие слои ссылаются на него.
Вопрос 1: Это верно?

Я действительно обеспокоен уровнем обслуживания.Я замечаю, что разрабатываю очень анемичную модель по двум причинам: 1, моя модель не ссылается на репозиторий, поэтому я ничего не могу сохранить через модель.2, я пытаюсь делать вещи, как они происходят (т.е. я добавляю объект в список объектов, поэтому я сохраняю его в БД по одному, а не все сразу, когда пользователь завершает добавление объектов).Таким образом, большая часть работы выполняется между слоями Service и Rep, а модель просто находится там и выглядит красиво.

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

1 Ответ

2 голосов
/ 03 ноября 2011

Модель должна быть основой всего. Он не ссылается ни на что, другие слои ссылаются на него. Вопрос 1: Это верно?

Типичный способ обеспечить разделение между моделью предметной области и системой персистентности - определить репозитории. Однако постоянство не является частью модели предметной области.

Ваши модели должны вызывать методы, определенные в хранилище

Например, рассмотрим этот полностью поддельный репозиторий: 

// Repository
public class SharepointRepository
{
   void SaveWidget(); // Implement
}

Таким образом, хранилище занимается только загрузкой и сохранением данных, они вообще не содержат никакой логики вашего домена.

Однако, если ваша модель тесно связана с хранилищем, у вас возникает проблема разделения проблем.

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

namespace YourApp.Domain.Abstract
{
    public interface ISharePointRepository
    {
        void SaveWidget();
    }
}

На основе этого интерфейса вы можете создать конкретную реализацию и внедрить зависимость от конкретной реализации во время выполнения. 

namespace YourApp.Domain.Concrete
{
    public class SqlSharePointRepository : ISharePointRepository
    {
        void SaveWidget()
        {
          // Code that Saves the widget using the managed sql provider
        }

    }
}

Итак, на вашей веб-форме:

Когда вы собираете данные, ваша модель будет гидратирована данными из формы и будет вызывать метод репозитория, однако сам репозиторий мог бы быть внедрен в приложение asp.net во время выполнения, поэтому вы можете изменить SqlSharePointRepository на RavenDbRepository, не ломая ваше приложение.

Чтобы узнать, как связать ваш репозиторий в Webforms, смотрите это сообщение SO: Как я могу реализовать Ninject или DI на веб-формах asp.net?

С MVC контроллер отвечает за разрыв, который, по вашему мнению, вы испытываете. Но что касается ваших вопросов и в зависимости от вашего текущего дизайна, модель должна вызывать операции с хранилищем, однако само хранилище должно быть слабо связанным.

...