Услуги .NET REST, Entity Framework и слабая связь - PullRequest
Новая
       34

Услуги .NET REST, Entity Framework и слабая связь

3 голосов
/ 12 июля 2011

Я работаю над проектом веб-приложения с использованием ASP.NET MVC3 и базы данных в SQL Server. Существует также мобильное приложение, которое использует данные из той же базы данных через службы REST. Вот несколько слоев моего приложения:

  • Модель - модель данных ADO.NET, использующая Entity Framework

  • Уровень доступа к данным - Хранилища с запросами для извлечения данных из базы данных

  • Веб-приложение - проект MVC3, использующий репозитории, слабая связь с использованием Structure Map и DI, контекст базы данных располагается в конце запроса HttpRequest

  • Core - еще один уровень между DAL и Service Layer, использует хранилища и предоставляет данные для Service Layer. Сортировка уровня бизнес-логики.

  • Сервисный уровень - REST-сервисы, знает о Базовом уровне, но не о DAL. Сопоставляет данные с DTO и предоставляет клиенту

Проблема, с которой я столкнулся при такой архитектуре приложения, заключается в слабой связи на уровне обслуживания. Сервисный уровень имеет ссылку на основной слой. Основной уровень имеет ссылку на уровень доступа к данным и использует его репозитории. У репозиториев нет конструктора по умолчанию. Они ожидают 1 параметр и его контекст объекта базы данных (одноразовый объект).

Использование репозиториев непосредственно на моем сайте не является проблемой. Я использую Structure Map, и DI делает его слабо связанным Каждый контекст располагается в конце запроса HttpRequest.

Проблема в том, что Service Layer и Core layer. Я бы тоже хотел иметь слабую связь, но не уверен, как этого добиться? Как внедрить в них контекст данных и убедиться, что он удаляется в определенный момент? Я хотел бы услышать несколько советов о том, как все это собрать вместе.

Ответы [ 2 ]

5 голосов
/ 12 июля 2011

Сервисный уровень имеет ссылку на базовый уровень.

Отлично.

Основной уровень имеет ссылку на уровень доступа к данным и использует его репозитории.

Это не хорошо.

Ваше «ядро» должно быть вашим доменом с бизнес-правилами и логикой. У него не должно быть никаких зависимостей.

Начните с низа стека:

  1. Репо - нет зависимости от других слоев.
  2. Сервисы - зависимость от Core и Repo.
  3. Ядро - нет зависимостей от других слоев.
  4. Сеть - зависит от всего.

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

Пример потока:

  1. HTTP-запрос приходит (API, веб-уровень и т. Д.)
  2. Контроллер найден. Контейнер DI видит, что контейнер имеет зависимость от ISomethingService, и разрешает его, включая любые дальнейшие зависимости (сервис, репо и т. Д.).
  3. Контроллер вызывает метод на ISomethingService.
  4. ISomethingService реализация (выбранная DI) вызывает метод на ISomeRepo.
  5. ISomeRepo Реализация (выбранная DI) вызывает EF / DB, возвращает «объект данных» в сервис.
  6. Служба сопоставляет «объект данных» с объектом «Core» и возвращает к контроллеру.

Создание этих объектов должно выполняться вашим DI-контейнером. Единственное, чего не хватает в вышеприведенном, что мы используем, - это «Единица работы», которая по существу оборачивает контекст EF.

1 голос
/ 12 июля 2011 
public ServiceLayerClass()
{
    private ICoreLayerClass coreLayerClass;

    public ServiceLayerClass(ICoreLayerClass coreLayerClass)
    {
        this.coreLayerClass = coreLayerClass;
    }

    public void DoSomeWork()
    {
        coreLayerClass.DoSomeWork();
    }
}

public CoreLayerClass()
{
    private ISomeRepository someRepository;

    public CoreLayerClass(ISomeRepository someRepository)
    {
        someRepository = this.someRepository;
    }

    public void DoSomeWork()
    {
        someRepository.DoSomeWork();
    }
}

public SomeRepository()
{
    public SomeRepository(IUnitOfWork uow)
    {
    }

    public void DoSomeWork()
    {
        //do some work
    }
}

Примечания: UnitOfWork в идеале должен быть создан в соответствии с HttpContext. т. е. ваш datacontext начнет свою жизнь в начале запроса и будет удален в конце. Вы будете использовать только один запрос.

...