Я должен использовать частичные классы в качестве бизнес-слоя при использовании платформы объекта?

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

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

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

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

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

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

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

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

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

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

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

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

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

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