Я работаю со старшим разработчиком, который является гуру .NET архитектором.За последние 6 с лишним месяцев у нас было много конструктивных аргументов, и в большинстве случаев я признаю поражение.Я изучил стеки от работы с ним.Однако есть одна проблема с дизайном, с которой мы в настоящее время не согласны, и я хотел бы получить некоторые мнения / предложения, потому что ему не удалось убедить меня в своей позиции, и я буду придерживаться своего оружия, пока кто-нибудь не сможет дать мне доказательство того, что яЯ ошибаюсь.
Мы используем Entity Framework 4.0, и мы используем ОБЕСПЕЧЕНИЕ постоянства и САМОСЛЕДУЕМЫЕ сущности в разных моделях.Мы начали использовать Self Tracked Entities для отслеживания изменений в Entity Graphs, которые мы сериализовали / десериализовали через провод WCF в наше приложение Silverlight.Это работает фантастически.Мы также начали использовать Self Tracked Entities для моделей, которые мы НЕ применяем в WCF, но многие остаются постоянными осведомленными объектами / моделями.
Мой коллега считает, что Entity Frameworks ObjectContext следует хранить для кратчайшеговремя возможно.Он настаивает на том, что он должен существовать только в течение периода времени, необходимого для выполнения запроса, и периода времени, необходимого для сохранения чего-либо.Любая деловая работа с сущностями должна выполняться отдельно.Для каждой имеющейся у нас модели сущностей у нас есть класс запроса и постоянный класс, которые являются IDisposable и имеют ObjectContext в области видимости экземпляра и имеют логику запроса / постоянства в методах.Мы используем эти классы запросов / постоянства в нашей бизнес-логике, а не используем ObjectContext непосредственно в бизнес-логике.Когда эти экземпляры класса сконструированы, то же самое относится и к ObjectContext, а когда Disposed, так и к ObjectContext Disposed.Эти классы подобны оболочкам вокруг наших операций LINQ, отделяющих EF от бизнес-логики и помогающим с повторным использованием запроса LINQ.
Теперь сначала рассмотрим объекты, отличные от Self Tracked:
Я понимаю, почему он хочетэто и желание не иметь долго работающего ObjectContext, но моя проблема в том, что он всегда хочет, чтобы даже тривиальная бизнес-логика была отделена от ObjectContext, и тот факт, что у нас есть отдельный контекст запроса и персистентности в нашем дизайне, означает, что нетОтслеживание состояния ObjectContext сущностей, используемых в нашей бизнес-логике.Для сущностей, которые не отслеживаются самостоятельно, это означает, что если мы изменяем сущности в нашей бизнес-логике, мы также должны вручную установить состояние измененных сущностей перед сохранением.Это НАСТОЯЩАЯ боль при сохранении сложных графиков с несколькими изменениями.Также я сомневаюсь, что мы можем сделать это вручную, как это делает EF автоматически.
Для наших самоотслеживаемых объектов такая же ситуация, потому что отслеживание включается только тогда, когда графы десериализованы, и поэтому при работе ВСлужба, в которой был выполнен запрос, отделена от контекста, отслеживание с помощью самопровозглашенных объектов по-прежнему отсутствует.
У меня такой вопрос, каков наилучший способ использования Entity Framework и каким должен быть DAL Entity Frameworkпредназначен?Как долго должен быть ObjectContext?Должна ли бизнес-логика всегда выполняться отдельно от ObjectContext?Если да, то как мы можем отслеживать состояние, когда работаем отдельно от ObjectContext?Один из вариантов, о котором я думаю, - это преобразование ВСЕХ наших сущностей в Само-отслеживаемые сущности и использование некоторого кода обхода графа для обхода запрашиваемых графов и включения отслеживания для всех сущностей в графе, чтобы самостоятельное отслеживание было включено даже при работе сервисной стороны.(в основном подражая тому, что происходит, когда граф Self-Tracked Entities десериализован) ...
Я не предлагаю, чтобы мы сохраняли ObjectContext в течение долгого времени, но работали отдельно между запросом и постоянством ипотерять преимущества отслеживания состояния ObjectContext для меня кажется глупым ... мы теряем одно из больших преимуществ EntityFramework ...
Извините за длинный пост ... любая помощь приветствуется.