Nano Hash - криптовалюты, майнинг, программирование

доменное проектирование с использованием Entity framework 4

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

Использование сущностей Entity Framework в качестве бизнес-объектов?

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

Эта ссылка четко объясняет проблему

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx#id0420099

.net architecture design-patterns entity-framework entity-framework-4
20.10.2011

Ответы:


1

Это зависит от того, насколько слабо связаны вы хотите / должны быть.

Возьмем, к примеру, приложение WPF / MVVM, которое общается со службой через WCF и хранит данные с помощью EF. Тогда, если вы пройдете весь путь, у вас будет следующее:

На клиенте:

  • Вид
  • ViewModel
  • Модель

Между клиентом и сервером:

  • Объект передачи данных

На сервере:

  • Субъекты хозяйствования
  • EF Entities

С кодом сопоставления между каждым слоем. Это может быть большая работа и дублирование между объектами. Слишком много слоев может оказаться непрактичным. Мы стараемся комбинировать их там, где это возможно, например, может ли DTO быть моделью?

Используя частичные классы, вы можете добавить функциональность к классам EF, которые не будут удалены при повторном создании модели. Таким образом, вы могли бы использовать их как свои бизнес-объекты.

Я бы не стал использовать их как DTO по следующим причинам:

  • Изменение в базе данных может повлиять на многие системы.
  • Клиенты без MS могут пользоваться вашими услугами
20.10.2011

2

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

Существуют твердые мнения, которые выступают за использование DTO / POCO (обычные старые объекты среды CLR), и действительно вы можно использовать EF для генерации DTO для достижения этой цели. Это своего рода Rolls-Royce с точки зрения архитектуры ... Ключевым преимуществом является то, что вы отделяете свою бизнес-логику от доступа к данным, а затем теоретически можете переключиться на новейшую и лучшую ORM в будущем. Недостатком является то, что (как вы сказали в своем вопросе) вам нужна картографическая служба для перевода между двумя слоями, а также тот факт, что вы, по сути, получаете несколько классов для представления одного и того же фрагмента данных.

Как правило, использование DTO / POCO не рекомендуется для малых / средних из-за добавленного раздувания кода, однако для более крупных проектов разделение проблем может быть выгодным, несмотря на добавленное кодирование объемов. Корпоративное приложение или нет, я думаю, вам нужно учитывать реальность того, захотите ли вы когда-нибудь выключить свой инструмент ORM (то есть EF).

Вдобавок я думаю, что классы, созданные EF, уже достаточно просты и скрывают большую часть кода доступа к данным в файле ".designer.cs", а то и большую часть с декларативными атрибутами.

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

Ознакомьтесь с этим series статей для получения дополнительной информации.

20.10.2011
  • Я согласен с тем, что я могу поместить свою бизнес-логику в частичные классы сущностей EF, чтобы защитить ее от изменений в модели данных. но я хочу сказать, что если я хочу разрабатывать свои бизнес-объекты иначе, чем модель данных, возможно ли это? Я хочу сказать, что проектирование модели данных выполняется с использованием принципов нормализации данных, а не с использованием объектно-ориентированных принципов, поэтому он может не подходить для проектирования модели предметной области. 21.10.2011
  • EF предназначен для предоставления объектно-ориентированных схем данных. Например, предоставляя свойства навигации, наследование и другие подобные полезности. 21.10.2011
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..