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

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

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

1. Созданная модель сущностей включает в себя глубокую реляционную объектную модель, которая, в зависимости от вашей схемы, будет доступна на уровне пользовательского интерфейса (например, презентатор 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.

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

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

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

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

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

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

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

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

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

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

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