Можно ли развязать сгенерированные объекты LINQ to SQL?

Question

Мне нравится LINQ to SQL, но создается впечатление, что сгенерированные им классы тесно связаны с базой данных, в которой они хранятся, что кажется плохим.

Например, при использовании старой базы данных Northwind, если я создаю dbml с таблицей Products, создается класс Product. Я могу использовать этот класс на любом другом уровне, и это хорошо, но если я решу, что предпочитаю использовать обычный старый ADO.NET (или переключать базы данных), мне придется заново создать класс Product вместе с любой другой "моделью".

Есть ли способ обойти это? Или создать ваши объектные модели отдельно, а затем сопоставить таблицы с ними? Я играл с различными классами картографии, но пока не нашел удовлетворительного ответа.

Answer 1

Все эти ответы и без ссылок! Может быть, я могу помочь:

Атрибуты, которые упоминал Дамиенг

Частичное занятие, о котором говорил Маркус Кинг

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

[Table(Name="Products")]
public partial class Product: IProduct { }

И да, к сожалению, потребовалось некоторое волшебство отражения, чтобы заставить его работать для реализации POCO.

В конце концов, если вы действительно обеспокоены этим, я бы выбрал NHibernate (мне это тоже не очень нравится), который делает именно то, что, по-видимому, описывает Гарри Шултер.

Надеюсь, это поможет!

Answer 2

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

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

Если для вас важно постоянное невежество, возможно, вам лучше обслужить полноценный ORM, такой как NHIbernate.

Answer 3

О, эй, я думаю, что нашел решение этой проблемы во время просмотра Роба Конери на экране ASP.NET MVC . Хитрость заключается в select в объекте в вашем запросе LINQ to SQL.

public IQueryable<LinqExample.Core.Person> GetAll() {
    var people = from pe in this.db.Persons
                 select new Person {
                     Id = pe.id,
                     FirstName = pe.fname,
                     LastName = pe.lname,
                     Reports = this.GetReports(pe.id)
                 };
    return people;
}

Это позволяет вам определить класс Person в другом месте вашего кода. Я написал об этом подробнее.

Answer 4

Недавно я достиг этого, создав сам POCO и вручную создав файл сопоставления XML для базы данных. Это требует немного ручной работы, но дает желаемый эффект.

Вот блог , который я нашел полезным , чтобы вы начали.

Answer 5

Linq to SQL (или EF) - , а не о невежестве. Речь идет об объектном представлении данных.

NHibernate - это постоянное невежество ORM, которое вы, возможно, ищете.

Answer 6

Скотт Хансельман выступил на экране, говоря о динамических данных asp.net, где он использовал классы Linq To Sql. Хотя он не рассматривал конкретную проблему, я думаю, что общая концепция все еще будет работать. Его подход заключался в создании отдельного частичного класса, который имел бы то же имя, что и класс, Product в вашем случае, который был сгенерирован dbml. Тогда у вас всегда должен быть класс Product, который существует вне того, что генерирует LINQ, и просто «расширяет» то, что он делает.

Answer 7

Просто скопируйте сгенерированный код в ваши собственные классы и отключите генерацию кода. Магия в атрибутах, а не что-нибудь еще.

Кроме того, вы можете написать свои собственные простые объекты CLR без атрибутов и использовать внешний файл сопоставления XML для описания отношений между объектами и базой данных. Дополнительную информацию можно найти в документации по LINQ to SQL на MSDN.