EF + WCF в трехслойном приложении со сложными графами объектов.Какой шаблон использовать?

Question

У меня архитектурный вопрос об EF и WCF. Мы разрабатываем трехуровневое приложение, используя Entity Framework (с базой данных Oracle) и графический интерфейс на основе WPF. Графический интерфейс связывается с сервером через WCF.

Наша модель данных довольно сложна (более ста таблиц), с множеством связей. В настоящее время мы используем шаблон генерации кода EF по умолчанию, и у нас много проблем с отслеживанием состояния наших объектов.

Пользовательские интерфейсы на клиенте также довольно сложны, иногда граф объектов с более чем 50 объектами отправляется на один пользовательский интерфейс с несколькими уровнями агрегации между объектами. Важной целью является возможность легко определить на уровне BLL, какие из объектов были изменены на клиенте, а какие объекты были недавно созданы.

Каким будет самый ясный подход к управлению объектами и состояниями объектов между двумя уровнями? Самостоятельное отслеживание сущностей? Каковы наиболее распространенные подводные камни в этом сценарии?

Могут ли те, кто использовал STE в реальной производственной среде, рассказать о своем опыте?

Answer 1

Мы разработали многоуровневое приложение с STE.Уровень пользовательского интерфейса с ASP.NET и ModelViewPresenter, бизнес-уровень, уровень службы WCF и уровень данных с Entity Framework.

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

Но мы столкнулись с множеством проблем при использовании STE.Одна из основных проблем заключается в том, что если ваши сущности поступают из нескольких сервисных вызовов (например, из основного подробного представления) и, следовательно, из разных контекстов, вы столкнетесь с проблемами при составлении графиков на сервере и попытке их сохранения.Таким образом, наша серверная функция все еще должна вручную проверять, какие данные были изменены, а затем повторно составлять граф объектов на сервере.Много было написано на эту тему, но все еще не легко исправить.

Другая проблема, с которой мы столкнулись, заключалась в том, что STE не будет работать без WCF.Отслеживание изменений активируется при сериализации объектов.Первоначально мы разработали архитектуру, в которой WCF можно было бы отключить, а вызовы служб просто выполнялись (это было требованием для наших модульных тестов, которые выполнялись бы намного быстрее без wcf и были бы проще в настройке).Оказалось, что STE не правильный выбор для этого.

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

После этого проекта мы 'Мы решили использовать пользовательские DTO с автоматом от сервера к клиенту и использовать шаблон POCO в нашем слое данных в новом проекте.

Так как вы уже заявляете, что ваш проект большой, я бы выбрал пользовательские DTO и сервисные функции, которые специально созданы для одной цели, вместо функций «Обновление (Person))», которые отправляют много данных

Надеюсь, это поможет:)

Answer 2

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

• Соединение вашего уровня данных с клиентским приложением - вы должны совместно использовать сборку сущностей между проектами (это также означает, что это решение только для .NET, но в вашем случае это не должно быть проблемой)
• Передача больших объемов данных - вы передаете 50 сущностей клиентам, клиент меняет одну сущность, и вы передаете 50 сущностей обратно. Это потребует некоторой борьбы с STE, чтобы избежать передачи ненужных данных
• Ненужные обновления базы данных - обычно, когда EF работает с присоединенными сущностями, он отслеживает изменения на уровне свойств, но с STE он отслеживает изменения на уровне сущностей. Поэтому, если пользователь изменит одно свойство в объекте со 100 свойствами, он сгенерирует обновление с настройкой всех из них. Во избежание этого потребуется изменить шаблон и добавить отслеживание изменений уровня свойств.
• Клиентское приложение должно использовать STE напрямую (связывая STE с пользовательским интерфейсом), чтобы получить большую часть возможностей самостоятельного отслеживания. В противном случае вам придется реализовать код, который переместит данные из пользовательского интерфейса обратно в само отслеживаемый объект и изменит его состояние.
• Они не проксируются = они не поддерживают отложенную загрузку (в случае службы WCF это хорошее поведение)

Я описал сегодня способ решить это без STEs . Есть также связанный вопрос о отслеживании через веб-сервисы (проверьте ответ @ Richard и предоставленные ссылки).