Это - плохая практика для добавления функциональности к объектам EF с помощью частичных классов?
Я создаю маленькое приложение синхронизации с помощью шаблона 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; }
}
}
Это - плохая практика для отбрасывания дополнительной логики прямо на сгенерированные объектом классы? Я должен сделать другой доменный слой для этой логики?
3 ответа
Вы делаете именно то, для чего были разработаны частичные классы; добавление соответствующей логики в генерируемый кодом класс без остановки дерева наследования. Так держать.
Дополнение:
Со страницы, выделенной шрифтом всех племенных знаний, Википедия (выделено автором):
Целью частичных классов является разрешить определение класса охватить через несколько файлов. это особенно полезно для:
- Очень больших классов (в которых неудобно работать с редактором через один файл)
- Разделение задач аналогично аспектно-ориентированному программированию. но без использования каких-либо дополнительных инструментов. An пример показан ниже.
- Разрешение нескольким разработчикам работать над одним классом одновременно время без необходимости позже слияние файлов в системе контроля версий.
- Разрешение разделения между интерфейсом класса и определения, связанные с реализацией (Отдельные определения общественности и частные части)
- Упрощение написания генераторов кода, таких как визуальные дизайнеры.Это, пожалуй, самый полезный причина. Разработка - это вызов генераторы кода, которые могут управлять сгенерированный код, когда он помещается в код, написанный человеком:
- Требуется тщательный анализ ненужного кода, чтобы найти место для вставки сгенерированного кода. Изменение кода также является проблемой. Плохо написанные генераторы удерживают потенциальный риск повреждения всего файл.
Используя частичные классы, код генератор обрабатывает отдельный файл, и, таким образом, избавляется от всех вышеупомянутые проблемы.
Я должен признаться, что поступал так с POCO и считаю это очень продуктивным. Другое распространенное использование
- Fullname = FirstName + "" + Surname
- CostIncl = Excl + Tax
- Иногда также можно агрегировать итоги в дочерних объектах (например, InvoiceTotal = Sum of all LineItem.Totals)
и т. Д.
Есть некоторые предостережения
- . Если вы отправляете эти сущности напрямую по сети (например, WCF или ASMX), убедитесь, что они не помечены как Serializable / DataMember, поскольку они не смогут сериализовать без установщика
- И если вы не являются (например, сопоставление их по сети или для целей MVVM), вам нужно будет продублировать усилия
- Изменить: согласно комментарию Стивена, использование производного свойства в запросе LINQ (которое попадает в SQL) не удастся (поскольку оно не может быть сопоставлен с SQL).
Неплохо использовать частичные классы сущностей при использовании Entity Framework. Однако вам просто нужно убедиться, что вы не смешиваете бизнес-логику с логикой доступа к данным в членах частичных классов. В противном случае будет сложно написать код модульного теста без подключения к базе данных.
Пример BookLibrary из WPF Application Framework (WAF) показывает, как может выглядеть приложение WPF MVVM, когда уровень домена использует EF Entities.