Должен ли я использовать частичные классы в качестве бизнес-уровня при использовании структуры сущностей?

Question

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

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

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

Answer 1

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

Объекты могут использоваться для слоя данных, но они не должны. Если вообще, укажите интерфейсы, которые будут использоваться, и пусть ваши объекты реализуют их (в частичном файле), BL не должен знать объекты, кроме интерфейсов.

Answer 2

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

В качестве альтернативы вы также можете изучить код EF4 только для того, чтобы вам не нужно было создавать вашу модель из базы данных.

Answer 3

Я бы не сделать это по следующим причинам:

1. Вы теряете четкое различие между слоем данных и бизнес-слой
2. Это делает бизнес-слой более трудно проверить

Однако, если у вас есть определенный код модели данных, поместите это частичный класс, чтобы избежать его потери при регенерации модели.

Answer 4

Я бы использовал частичные классы. В DDD-ish-коде отсутствует такая вещь, как уровень данных. Существует уровень данных, и он находится на SQL Server. Код приложения должен содержать только бизнес-уровень и некоторые сопоставления, которые позволяют сохранять существующие бизнес-объекты в указанном уровне данных.

Entity Framework - это код доступа к данным, поэтому вы не должны создавать свои собственные. В большинстве случаев схема базы данных будет изменена, потому что модель изменилась, а не наоборот.

Это, как говорится, я бы обескуражил, чтобы вы делились своими сущностями во всех слоях. Я ценю разделение интерфейса и домена. Я бы использовал DTO для передачи данных в и из домена. Если у меня будет необходимая свобода, я бы даже использовал шаблон CQRS, чтобы избавиться от отображения объектов в DTO - я бы просто создал второй проект доступа к данным EF, предназначенный только для чтения данных для пользовательского интерфейса. Он будет построен поверх той же базы данных. Вы читаете данные с помощью модели read (anemic - без бизнес-логики), но вы изменяете ее, выдавая команды, которые выполняются с реальной моделью, реализованной с использованием EF и частичных методов.

Ответит ли это на ваш вопрос?

Answer 5

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

По несколько причин:

1. Модели лица, созданная включает в себя глубокую реляционную модель объекта, которая, в зависимости от схемы, получила бы подверженную слой UI (скажем, выступающие от MVP или ViewModel в MVVM).
2. Уровень бизнес-логики обычно раскрывает операции, которые вы можете кодировать. Если вы видите метод сохранения в BLL и посмотрите параметры, необходимые для сохранения, и посмотрите модель, которая требует создания других объектов (причина реляционного характера модели сущности), просто для сохранения, она не поддерживает операция простая.
3. Если у вас есть куча веб-сервисов, тогда дополнительные данные должны быть отправлены без видимой выгоды.
4. Вы можете создать более неизменяемые DTO для своих параметров работы, а не сталкиваться с побочными эффектами, поскольку один и тот же экземпляр был изменен в какой-либо другой части приложения.

5. Если вы делаете TDD и следуете YAGNI, тогда вы будете иметь тенденцию иметь структуру, специально предназначенную для операции, которую вы пишете, что было бы легче построить тесты против (не требуя создания других объектов, не доведенных до теста, они находятся на модели). В этом случае вы могли бы ...

   public class Order 
   { ... 
       public Guid CustomerID { get; set; } 
   ... } 
   

Вместо использования модели Entity порожденной EF, которые имеют ссылки на открытые ...

public class Order 
{ ... 
    public Customer Customer { get; set; } 
... } 

Таким образом, идентификатор клиента требуется только для операции, которая принимает порядок. Зачем вам нужно построить Customer (и, возможно, другие объекты) для операции, связанной с принятием заказов?

Если вы беспокоитесь о дублировании и отображения, то взгляните на Automapper