Почему TableAttribute в Entity Framework Dll?

Question

Есть ли веская причина, по которой атрибут Table (который можно использовать для сопоставления класса POCO с правильным именем / схемой базы данных) находится в EntityFramework.dll?

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

Это упущение, или я что-то упустил?

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

Answer 1

Я думаю, потому что TableAttribute был добавлен в EF 4.1.Он принадлежит пространству имен System.ComponentModel.DataAnnotations и, вероятно, был бы добавлен в сборку System.ComponentModel.DataAnnotations.dll, если бы EF 4.1 был частью обычной версии .NET Framework.Но поскольку EF 4.1 был выпущен независимо от обновления Framework, они не могли коснуться сборок ядра Framework.Итак, на данный момент он находится в EntityFramework.dll, но все еще в System.ComponentModel.DataAnnotations пространстве имен, так или иначе независимом от Entity Framework.Возможно, он будет перемещен в System.ComponentModel.DataAnnotations.dll со следующей версией .NET Framework.

На данный момент, если вы хотите украсить свои POCO с помощью TableAttribute, вы должны ссылаться на EntityFramework.dll.Я бы не стал рассматривать это как зависимость от Entity Framework, если вы не используете «настоящие» вещи EF (DbContext и т. Д.) В своей пользовательской сборке.

Answer 2

Это вызывает проблемы для Silverlight.

Для тех, кто борется с этим, на данный момент вы должны использовать свободный API для создания карт.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<BankAccount>().ToTable("BankAccounts");
    modelBuilder.Entity<CreditCard>().ToTable("CreditCards");
}

НТН.