LINQ To SQL объекты объектов как объекты домена

Question

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

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

Скажем, у меня есть класс UserDAL, должен ли он предоставлять объект User объекта сущности при вызове метода GetByID (), или он должен выплевывать простой объект данных исключительно для хранения данных и ничего более? (в данном случае это похоже на расточительное дублирование)

Что вы, ребята, сделали в такой же ситуации? Есть ли альтернативный метод этому?

Надеюсь, это было не слишком расплывчато.

Большое спасибо,

Martin.

Answer 1

Я возвращаю IQueryable POCO из моего DAL (который использует LINQ2SQL), поэтому ни один объект сущности Linq никогда не покидает DAL. Эти POCO возвращаются на уровни обслуживания и пользовательского интерфейса, а также используются для передачи данных обратно в DAL для обработки. Linq отлично с этим справляется:

 IQueryable<MyObjects.Product> products = from p in linqDataContext.Products 
                                          select new MyObjects.Product //POCO
                                          {
                                              ProductID = p.ProductID
                                          };
 return products;

Answer 2

Для большинства проектов мы используем сущности LINQ to SQL в качестве наших бизнес-объектов.

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

Есть даже статья о реализации вашей бизнес-логики таким образом на MSDN.

Это избавляет вас от написания лота утомительного стандартного кода, и вы даже можете сделать свои объекты сериализуемыми , если хотите вернуть их из веб-службы.

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

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

Answer 3

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

В небольших приложениях я нахожу вторую реализацию POCO расточительной, в более крупных приложениях (особенно в тех, которые реализуют веб-службы) полезен объект POCO (обычно объект передачи данных).

Если ваше приложение попадает в более поздний случай, вы можете посмотреть ADO.Net Data Services .

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

Answer 4

Мне лично не нравится, когда мои сущности распространяются по слоям. Мои DAL возвращают POCO (конечно, это часто означает дополнительную работу, но я нашел это намного чище - возможно, это будет проще в следующей версии .NET; -)).

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

Может быть, вы могли бы взглянуть на пример приложения MVC Storefront : мне нравится суть этой концепции (особенно отображение на уровне данных).

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

Answer 5

Имейте в виду, что Linq to SQL не является перспективной технологией. Он был выпущен, с ним интересно играть, но Microsoft никуда не денется. У меня такое чувство, что оно не будет поддерживаться вечно. Взгляните на Entity Framework (EF) от Microsoft, который включает в себя некоторые достоинства Linq to SQL.

Answer 6

Вместо стандартного MSLinqToSQLGenerator я использую собственный генератор LinqToSQL, построенный на основе того, что я нашел в Интернете Чтобы сделать мои верхние уровни независимыми от таких объектов Linq, я создаю интерфейсы для представления каждого из них, а затем использую такие интерфейсы в этих слоях. Пример:

public interface IConcept {
    long Code { get; set; }
    string Name { get; set; }
    bool IsDefault { get; set; }
}

public partial class Concept : IConcept { }

[Table(Name="dbo.Concepts")]
public partial class Concept
{
    private long _Code;
    private string _Name;
    private bool _IsDefault;
    partial void OnCreated();
    public Concept() { OnCreated(); }
    [Column(Storage="_Code", DbType="BigInt NOT NULL IDENTITY", IsPrimaryKey=true)]
    public long Code
    {
             //***
    }
    [Column(Storage="_Name", DbType="VarChar(50) NOT NULL")]
    public string Name
    {
             //***
    }
    [Column(Storage="_IsDefault", DbType="Bit NOT NULL")]
    public bool IsDefault
    {
             //***
    }
}

Конечно, есть гораздо больше, но это идея.

Answer 7

Я на самом деле тоже боролся с этим. Используя простой ванильный LINQ to SQL, я быстро отказался от инструмента DBML, потому что он тесно связывал сущности с DAL. Я стремился к более высокому уровню невежества, хотя Microsoft не делала это очень легким.

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

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

В ожидании Entity Framework невежество в постоянстве является часто запрашиваемой функцией в соответствии с блогами разработчиков для команды EF. В то же время, если вы решите пойти по пути EF, вы всегда можете обратиться к заранее подготовленному инструменту невосприимчивости к постоянству, например, к проекту EFPocoAdapter в MSDN.