Entity Framework Brainmush Kerfuffle Spectacular

Question

Я изучал все новые возможности EF и WCF в .NET 4 для крупного проекта на его ранних стадиях, и я думаю, что мой мозг теперь официально превратился в шлам. Это первая крупномасштабная работа по разработке, которую я сделал в .NET за 1.1 дня. Как обычно, все должно быть сделано вчера, поэтому я играю в догонялки.

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

На стороне сервера:

• Служба WCF, реализация используя EF для подключения к SQL Server хранилище данных (это, вероятно, в конечном итоге имея много сотен таблиц и всех других атрибутов сложной системы БД)
• Базовые классы, используемые для EF и WCF должен быть расширяемым как на свойство и класс (то есть поле и запись) уровень, для проверки, безопасность, аудит на высоком уровне и другая пользовательская логика

На стороне клиента:

• клиент WCF
• Базовые классы такие же, как на стороне сервера, но с некоторыми из настройки отсутствуют
• Когда объект обновляется на клиент, желательно только модифицированный свойства должны быть отправлены Сервер
• Детали API WCF на стороне клиента будут вероятно, в конечном итоге будет опубликовано публично, такая чувствительная сторона сервера реализации подсказки не должно быть просочился через API, если абсолютно неизбежно - это включает атрибуты EF в свойствах и занятия

Общие требования:

• Эффективность сети важна, поскольку мы не хотим этого делать * в * эффективный с первого дня - я могу предвидеть трафик данных и сервер рабочая нагрузка растет в геометрической прогрессии в течение нескольких лет
• База данных разрабатывается первой, поэтому классы (POCO, C #), сгенерированные EF будет основываться на этом. Как-то они нужно сделать подходящим для EF и WCF на клиенте и на стороне сервера, и имеют различные слои настройки, но выглядят так, как будто на заказ для каждого сценария

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

Может кто-нибудь указать мне общее направление, как построить классы, чтобы сделать все это? Честно, большое спасибо.

Answer 1

Несколько подсказок в произвольном порядке:

• POCO - это способ избежать зависимости от классов EF в ваших объектах данных.
• Рассмотрите возможность добавления промежуточного уровня на основена передачу данных передаются объекты, чтобы справиться с вашими «только измененными свойствами» (это требование будет сложной частью).Эти DTO будут передаваться между службой и клиентами для обмена модификациями
• Использовать модель связи без состояния (без сеанса WCF), чтобы можно было очень легко реализовать распределение нагрузки и переключение при сбое.
• SharePOCO между клиентом и службами, используйте подклассы на сервере, чтобы добавить внутреннюю настраиваемую информацию.

В конечном итоге на стороне сервера вы получите как минимум:

• Aпроект для сервисных контрактов и DTO (общий)
• проект для POCO (общий)
• проект для сервисного уровня WCF
• проект для бизнес-логики (вызов уровнем WCF)

Answer 2

У меня есть несколько примечаний к вашим требованиям:

Служба WCF, реализация используя EF для подключения к SQL Server хранилище данных (это, вероятно, в конечном итоге имея много сотен столов и все другие принадлежности комплекса Система БД)

Собираетесь ли вы строить только уровень доступа к данным, представленный как набор служб WCF, или сложную бизнес-логику, представленную как службы WCF? Это сильно повлияет на остальные ваши требования. Если вы хотите сделать первый случай, проверьте службы данных WCF. В последнем случае проверьте мои другие заметки.

Базовые классы, используемые для EF и WCF должен быть расширяемым как на имущество и уровень класса (то есть поля и записи), для проверки, безопасности, высокого уровня Аудит и другая пользовательская логика

Разделите ваши классы данных на два набора. Внутренне ваши сервисы будут использовать классы POCO, реализованные как объекты домена. Доменные объекты будут материализованы / сохранены EF (вам нужен .NET 4.0), и они также будут содержать собственную логику. Если вы хотите создать сложный бизнес-уровень, вам также следует подумать о доменно-ориентированном дизайне = репозитории, совокупные корни и т. Д.

Базовые классы такие же, как на стороне сервера, но с некоторыми из настройки отсутствуют

Вторым набором классов данных будут объекты передачи данных, которые будут доступны службам WCF и будут использоваться сервером и клиентами. Ваши доменные объекты будут преобразованы в DTO при отправке данных клиенту, а DTO будут преобразованы в доменные объекты при возврате из клиента.

Ваши сервисы WCF должны быть построены на основе бизнес-логики - доменные объекты / доменные сервисы. Службы WCF должны предоставлять короткие интерфейсы (вместо диалоговых CRUD-интерфейсов), где DTO передает данные из нескольких операций домена. Это также поможет вам повысить производительность, сократив количество циклов между клиентом и сервисом.

Когда объект обновляется на клиент, желательно только модифицированный свойства должны быть отправлены Сервер

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

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

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

База данных разрабатывается первой, поэтому классы (POCO, C #), сгенерированные EF будет основываться на этом.

Это кажется простым требованием, но вы можете легко смоделировать базу данных, которую будет сложно использовать с Entity Framework.

Главный совет:

Ваш проект выглядит большим и сложным, поэтому первое, что вы должны сделать, это нанять разработчиков, имеющих опыт работы с WCF, EF и т. Д. У каждой из этих технологий есть свои подводные камни, поэтому использовать их в таких масштабах действительно без риска опытные люди.