Какой вариант Entity Framework использовать в корпоративном приложении на основе WCF - PullRequest
Новая
       37

Какой вариант Entity Framework использовать в корпоративном приложении на основе WCF

4 голосов
/ 19 июня 2011

Мы находимся в процессе разработки приложения с приблизительно 100 таблицами и сложной бизнес-логикой. Windows Forms будут использоваться на стороне клиента, а службы WCF с MSSQL - на сервере.

Пользовательские DTO используются для связи клиент-сервер, бизнес-объекты не распространяются.

Какой вариант Entity Framework использовать (и почему):

  • EF 4.0 EntityObjects
  • EF 4.0 POCO
  • EF 4.1 DbContext
  • Что-то еще

Требуется подход к базе данных.

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

Ответы [ 2 ]

2 голосов
/ 19 июня 2011

Какой вариант использовать?По сути, после того, как у вас есть пользовательский DTO, единственный вопрос заключается в том, хотите ли вы контролировать код сущностей (их базовый класс) и сделать их независимыми от EF?Вы хотите сначала использовать код?Если ответов на все вопросы нет, вы можете использовать EntityObjects.Если вы хотите, чтобы сущности оставались невежественными или использовали пользовательский базовый класс, вам следует перейти к POCO.Если вы хотите сначала использовать код или новый DbContext API, вам потребуется EF 4.1.Некоторые смежные темы:

Есть еще несколько вещей, которые следует учитывать при разработке уровня обслуживания.Вы должны знать о сложностях, с которыми вам придется столкнуться при использовании EF в WCF.Ваш сервис будет предоставлять данные приложению WinForms и работать с ними в «автономном режиме».Как только пользователь внесет все необходимые изменения, он отправит данные обратно в службу.Но тут возникает проблема - вы должны сказать EF, что изменилось.Например, если вы разрешаете пользователю изменять заказ со всеми его элементами заказа (изменение количества в элементах, добавление новых элементов, удаление некоторых элементов) , вы должны сказать EF, что именно изменилось , что было добавлено и что было удалено,Это легко, когда вы работаете с одной сущностью, но как только вы позволите пользователю изменять граф объектов (особенно отношения «многие ко многим»), это будет довольно сложно.Наиболее распространенным решением является загрузка всего графика и объединение состояния из входящих DTO в загруженный и присоединенный график.Другое решение - использовать Самообследуемые сущности вместо EntityObjects / POCOs + DTO.

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

2 голосов
/ 19 июня 2011

Основным преимуществом POCO является то, что эти классы могут быть вашими DTO, поэтому, если у вас уже есть пользовательские DTO, которые вы используете, POCO кажется немного избыточным.Однако есть и другие преимущества, которые могут иметь или не иметь ценность для вас, поскольку вы не упомянули модульное тестирование как требование.Если вы планируете писать модульные тесты, то POCO все еще остается в пути.Вы, вероятно, не заметите большой разницы между 4.0 POCO и 4.1, так как вы не будете использовать функцию первого кода (отказ от ответственности: я использовал только 4.0 POCO, поэтому я не очень хорошо знаком с какими-либо незначительными различиямимежду ними, но они кажутся более или менее одинаковыми - в основном я уже использовал POCO в 4.0 и не видел ничего, что заставило бы меня хотеть обновить все для использования 4.1).

Кроме того, в зависимости от того, планируете ли вы выполнить юнит-тестирование этого слоя, все еще имеет значение реализация шаблонов репозитория / единицы работы при использовании Entity Framework.Он служит для отвлечения логики доступа к данным (контекста), а не самих сущностей, и позволяет выполнять такие вещи, как макетирование контекста в модульных тестах.Я копирую шаблон T4 для своего контекста и использую его для создания интерфейса, затем редактирую шаблон T4 для контекста и заставляю его реализовать этот интерфейс и использовать IObjectSet<T> вместо ObjectSet<T>.Поэтому вместо: 

public class MyEntitiesContext
{
    public ObjectSet<MyClass> MyEntities
    ...
}

я получаю: 

public interface IMyEntitiesContext
{
    public IObjectSet<MyClass> MyEntities;
}

и 

public class MyEntitiesContext : IMyEntitiesContext
{
    public IObjectSet<MyClass> MyEntities
    ...
}

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

...