Entity Framework Self Tracking Entities в N-уровневом приложении

Question

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

У нас есть типичное приложение N-уровня:

• Клиент WPF
• Услуги WCF
• EF STE DTO's
• Уровень данных EF

Приложение загружает все известные типы бизнеса во время загрузки (в то же время, когда пользователь входит в систему), а затем загружает очень большую «рабочую партию» по требованию, эта партия составляет около 4–8 Мг и состоит из более чем 1000 операций объекты. Когда мы заканчиваем загрузку этого «Пакета», мы связываем все с ранее загруженными бизнес-типами и т.д ...

В итоге у нас в памяти около 2–5 тыс. Бизнес-объектов, все они правильно ссылаются, поэтому мы можем использовать LINQ на клиентской стороне и злоупотреблять ею, мы также делаем сложную математику для всех этих объектов на клиентской стороне, поэтому нам действительно нужно большой график.

Проблема возникает, когда мы хотим сохранить изменения в базе данных. С таким большим графом объектов мы вряд ли захотим пересылать все заново через Сеть.

Наш текущий подход, который мне не нравится, учитывая сложность шаблонов T4 до сих пор, состоит в том, чтобы отсоединять и прикреплять все при обновлении. Мы в основном хотим обновить данный объект, отсоединить его от остальной части графика, отправить его по сети, обновить его на стороне WCF, а затем снова присоединить его на стороне клиента. Основная проблема заключается в том, что когда вы хотите обновить связанные объекты, скажем, вы добавляете что-то, у которого есть ссылка на что-то, что также добавляется, затем еще одна ссылка на что-то измененное и т. Д. Это заставляет много клиентского кода быть уверенным, что мы не ничего не сломать.

Все это делается с помощью сгенерированного кода, поэтому речь идет о 200-800 строках кода T4 на шаблон.

То, на что я сейчас обращаю внимание, - это способ настроить сериализацию и десериализацию STE, чтобы я мог контролировать, что отправляется по сети или нет, и иметь возможность обновлять пакеты вместо одного STE. Проверяя ссылки, посмотрите, являются ли эти ссылки неизменными или нет; если нет, не сериализуйте, если да, сериализуйте и обновляйте все, просто подключив его к контексту на стороне WCF.

После некоторого изучения я нашел 2 решения этого метода.

Одним из них является написание пользовательского DataContractSerializer.

Второй способ - изменить шаблон STE, созданный EF, и поиграться с KnownTypeAttribute, вместо того, чтобы генерировать его для каждого ссылочного типа, чтобы он ссылался на метод, который проверяет объект, и помечает только те ссылки сериализации, которые не изменились. .

• Кто-нибудь когда-нибудь сталкивался с этим вопрос раньше?
• Какие решения вы использовали?
• С какими проблемами вы столкнулись? линия?
• Насколько легко было поддерживать шаблоны созданы?

Answer 1

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

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

Вмешательство во внутреннее поведение STE - лучший способ потерять некоторые изменения в некоторых угловых / неожиданных сценариях.

Btw. это как-то похоже на сценарий синхронизации локальной базы данных с глобальной - я никогда не делал этого, но он довольно распространен в smart-клиентах.