Если я понимаю вашу архитектуру, я думаю, что это не хорошо для 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 клиенте вы их не встретите.