Как я узнаю, что мне следует использовать объекты с самопроверкой или DTO / POCO? - PullRequest
8 голосов
/ 23 марта 2011

Какие вопросы я могу задать себе относительно нашего дизайна, чтобы определить, следует ли нам использовать DTO или объекты с самопроверкой в ​​нашем приложении?

Вот некоторые вещи, которые я знаю, чтобы принять во внимание:

  • У нас есть стандартное n-уровневое приложение с клиентом WPF / MVVM, сервером WCF и базой данных MS SQL.
  • Пользователи могут определять свой собственный интерфейс, поэтому данные, необходимые из службы WCF, необходимы.изменения в зависимости от того, какой интерфейс пользователь определил для себя
  • Модели используются как на стороне клиента, так и на стороне сервера для проверки.Мы не будем связываться напрямую с DTO или STE
  • Некоторые модели содержат свойства, которые загружаются из службы WCF по мере необходимости
  • Уровень базы данных рассылает нежелательные сообщения нескольким серверам / базам данных
  • На стороне сервера имеются проверки прав доступа, которые влияют на способ возврата данных.Например, некоторые данные частично или полностью маскируются в зависимости от роли пользователя
  • Наши ресурсы ограничены (время, рабочая сила и т. Д.)

Итак, как я могу определить, чтоправильно для нас?Я никогда раньше не использовал EF, поэтому я действительно не знаю, подходят ли нам STE или нет.

Я видел, как люди предлагают начинать с STE и применять DTO только в том случае, если это становится проблемой, однако мыв настоящее время имеются DTO и они пытаются решить, облегчит ли использование STE жизнь.Мы достаточно рано находимся в процессе, что переключение не займет слишком много времени, но я не хочу переключаться на STE только для того, чтобы выяснить, что оно не работает для нас, и приходится все переключать обратно.

Ответы [ 3 ]

9 голосов
/ 28 марта 2011

Если я понимаю вашу архитектуру, я думаю, что это не хорошо для STEs , потому что:

  • Модели используются как на стороне клиента, так и на стороне сервера для проверки. Мы не будем связываться напрямую с DTO или STE

Основным преимуществом (и единственным преимуществом) или STE является их способность к отслеживанию, но способность к отслеживанию работает, только если STE используется с обеих сторон:

  • Клиентский сервер запросов на данные
  • Сервер запрашивает EF и получает набор STE и возвращает их клиенту
  • Клиент работает с STE, модифицирует их и отправляет обратно на сервер
  • Сервер получает STE и применяет переданные изменения к EF => database

Вкратце: на стороне клиента или сервера нет дополнительных моделей. Для полноценного использования STE они должны быть:

  • Модель на стороне сервера (= нет отдельной модели)
  • Переданные данные в WCF (= без DTO)
  • Модель на стороне клиента (= нет отдельной модели, привязка напрямую к STE). В противном случае вы будете дублировать логику отслеживания при обработке событий изменения на связанных объектах и ​​изменении STE. (Клиент и сервер совместно используют сборку с STE).

Любой другой сценарий просто означает, что вы не пользуетесь способностями самообследования и они вам не нужны.

А как насчет других ваших требований?

  • Пользователи могут определять свой собственный интерфейс, поэтому данные, необходимые для службы WCF, изменяются в зависимости от того, какой интерфейс пользователь определил для них.

Это должно быть возможно, но убедитесь, что каждая "лениво загруженная" часть является отдельной структурой - не создавайте сложную модель на стороне клиента. Я уже видел вопросы, когда людям приходилось отправлять весь граф сущностей для обновлений, а это не то, что вы всегда хотите. Из-за этого я думаю, что вы не должны соединять загруженные части в один граф сущностей.

  • На стороне сервера имеются проверки прав доступа, которые влияют на способ возврата данных. Например, некоторые данные частично или полностью маскируются в зависимости от роли пользователя

Я не уверен, как вы на самом деле хотите этого добиться. STE не используют проекции, поэтому вы должны обнулять поля непосредственно в объектах. Помните, что вы должны делать это, когда объект не находится в состоянии отслеживания, или ваша маскировка будет сохранена в базе данных.

  • Уровень базы данных спамит на нескольких серверах / базах данных

Это то, что не является проблемой STE. Сервер должен использовать правильный контекст EF для загрузки и сохранения данных.

STE - реализация шаблона набора изменений. Если вы хотите использовать их, вы должны следовать их правилам, чтобы в полной мере использовать шаблон. Они могут сэкономить время при правильном использовании, но это ускорение идет с жертвой некоторых архитектурных решений. Как и любая другая технология, они не идеальны, и иногда их трудно использовать (просто следуйте тегу self-tracking-entity , чтобы увидеть вопросы). У них также есть серьезных недостатков , но в .NET WPF клиенте вы их не встретите.

4 голосов
/ 25 марта 2011

Вы можете выбрать STE для данного сценария,

  • Все STE являются POCO, .Net динамически добавляет один слой для отслеживания изменений.
  • Используйте шаблоны T4 для генерации STE, это сэкономит ваше время.
  • Использование таких инструментов, как Automapper, сэкономит ваше время на ручном преобразовании возвращенного контракта WCF-данных в Entity или DTO

Плюсы для STE -

  1. Вам не нужно вручную отслеживать изменения.
  2. В случае WCF вам нужно просто сказать applydbchanges, и он автоматически обновит сущность

Минусы для STE -

  1. STE тяжелее POCO из-за динамического отслеживания

Плюсы для POCO -

  1. Легкий вес
  2. Может легко соединяться с EF или nH

Минусы для POCO -

  1. Нужно вручную отслеживать изменения с помощью EF. (Болезненно)
0 голосов
/ 28 марта 2011

POCO - это прокси-сервер с динамическим прокси-сервером, и он не очень хорошо играет по проводам см. Эту статью об обходном пути, хотя .Таким образом, они могут быть сделаны, но IMO, вам лучше перейти на STE, так как я считаю, что они хорошо согласуются с разработкой WPF / MVVM.

...