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

Question

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

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

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

Answer 1

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

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

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

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

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

Вместо использования модели сущностей, сгенерированной EF, для которой открыты ссылки ...

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Это отвечает на ваш вопрос?

Answer 4

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

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

Answer 5

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

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