Использование классов в проектах на основе ORM

Question

Этот вопрос касается сценариев «наилучшего использования» в проектах с ORM, такими как NHibernate, Subsonic, Linq2SQL и т. Д. *

Все эти инструменты генерируют базовые классы сущностей, некоторые с атрибутами, другие без. Люди используют эти классы как свои бизнес-классы? Или существует оптовое копирование данных из сгенерированных ORM классов в созданные вручную бизнес-классы?

Спасибо.

Answer 1

Я склонен работать наоборот. Я создаю бизнес-объекты так, как они мне нужны, и создаю отображения NHibernate из моих объектов в данные. Вы можете сделать так, чтобы NHibernate сгенерировал для вас схему на основе ваших сопоставлений, или вы можете создать свою собственную схему и создать сопоставления для перехода между ними. Linq2Sql и Entity Framework не поддерживают это. Я не могу говорить с Subsonic по этому вопросу.

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

Answer 2

SubSonic и Linq2Sql являются одноранговыми преобразователями. Рассмотрим ситуацию, когда база данных нормализуется. Например, информация о сотруднике разбита на 3 разные таблицы, но в модели вашего домена вы бы хотели, чтобы только один объект Employee представлял информацию. Это где SubSonic и Linq2Sql терпят неудачу. NHibernate позволяет вам сопоставить объект вашего домена с несколькими таблицами. Также вы хотите держаться подальше от автоматически сгенерированного кода. NHibernate позволяет вам определять свой собственный домен POCO (обычный старый объект C #) и имеет различные способы, которые позволяют нам сопоставить это с таблицами в базе данных

Answer 3

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

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

Answer 4

Существует пара решений для всех упомянутых инструментов, ответ на них зависит от масштаба вашего проекта.

Вот аналогичный вопрос о LINQ to SQL , на который я недавно ответил.

Надеюсь, это поможет!