Плохо ли добавлять функциональность в сущности EF, используя частичные классы?

Question

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

Например:

// entity framework generated
partial class Lap {
  int Id { /* boilerplate */ }
  DateTime StartTime { /* etc */ }
  DateTime EndTime { /* etc */ }
}

// in my partial class (written by me)
partial class Lap {
  TimeSpan Duration {
    get { return EndTime - StartTime; }
  }
}

Это плохая практика - добавлять дополнительную логику прямо на сущностьклассы?Должен ли я сделать еще один слой домена для этой логики?

Answer 1

Вы делаете то, для чего были разработаны частичные классы;добавление соответствующей логики к классу, сгенерированному кодом, не увязая в дереве наследования.Продолжайте в том же духе.

Дополнение:

Со страницы со шрифтом всех племенных знаний Википедия (выделение добавлено):

Назначение частичных классов состоит в том, чтобы определение класса охватывало несколько файлов.Это особенно полезно для:

• Очень больших классов (где неудобно перемещаться с редактором по одному файлу)
• Разделение задач, подобно аспектуориентированное программирование, но без использования каких-либо дополнительных инструментов.Пример показан ниже.
• Разрешение нескольким разработчикам работать над одним классом одновременно без необходимости последующего объединения файлов в системе контроля версий.
• Разрешение разделения между интерфейсом класса иопределения, связанные с реализацией (отдельные определения публичной и приватной частей)
• Облегчение написания генераторов кода, таких как визуальные дизайнеры.Это, пожалуй, самая полезная причина. Трудно разработать генераторы кода, которые могут управлять сгенерированным кодом, когда он помещен в написанный человеком код:
  • Требуется много разборов ненужного кода.просто найти место для вставки сгенерированного кода.Изменение кода также является проблемой.Плохо написанные генераторы несут потенциальный риск повреждения всего файла.

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

Answer 2

Я должен признать, что делал это с POCO и нашел это очень продуктивным.Другие распространенные случаи использования

• Полное имя = имя_папки + "" + Фамилия
• CostIncl = Excl + Tax
• Иногда также может агрегировать итоги в дочерних объектах (например, InvoiceTotal = Sumиз всех LineItem.Totals)

и т. д.

Есть некоторые предостережения

• Если вы отправляете эти объекты напрямую по проводам (например, WCF или ASMX), убедитесь, что они не помечены как Serializable / DataMember, так как они не смогут сериализоваться без установщика
• И если вы этого не сделаете (например, отобразите их по проводам или для целей MVVM), вам нужно будет продублироватьусилие
• Редактировать: В соответствии с комментарием Стивена, использование производного свойства в запросе LINQ (который попадает в SQL) не удастся (поскольку его нельзя сопоставить с SQL).

Answer 3

Неплохо использовать частичные классы сущностей при использовании Entity Framework. Однако вам просто нужно убедиться, что вы не смешиваете бизнес-логику с логикой доступа к данным в членах частичных классов. В противном случае будет сложно написать код модульного теста без подключения к базе данных.

Пример BookLibrary из WPF Application Framework (WAF) показывает, как может выглядеть приложение WPF MVVM, когда уровень домена использует объекты EF.