LINQ to SQL в 3-х уровневой архитектуре

Question

В настоящее время я использую трехслойный архитектор (DAL, BLL, Presentation Layer).

Мне интересно, как я могу реализовать трехуровневую архитектуру, используя LINQ to SQL. Я не знаю, должен ли LINQ быть в DAL или BLL. LiNQ, похоже, объединяет DAL и BLL.

Кто-нибудь раньше реализовывал LINQ в трехслойной архитектуре?

Answer 1

Я использую Linq-to-SQL / XML и считаю свое приложение трехуровневым. Разница между приложениями до Linq заключается в том, что теперь уровень доступа к данным стал намного меньше и легче, что на самом деле очень хорошая вещь!

В моем старом DAL у меня были бы такие методы, как:

public virtual int CountCustomersInCountry(string country) {
    // Plug in raw SQL.
}

public virtual List<Customer> GetCustomersInCountry(string country) {
    // Plug in raw SQL.
}

public virtual int CountCustomersForDepartment(string department) {
    // Plug in raw SQL.
}

public virtual List<Customer> GetCustomersForDepartment(string department) {
    // Plug in raw SQL.
}

etc. etc. ad-infinitum

Теперь у меня есть следующие методы:

public virtual int Count(Expression<Func<T, bool>> where) {
    // Plug in Linq-to-SQL DataContext here.        
}

public virtual T Get(Expression<Func<T, bool>> where) {
     // Plug in Linq-to-SQL DataContext here.   
}

public virtual List<T> Get(Expression<Func<T, bool>> where,  string orderByField, int offset, int count) {
    // Plug in Linq-to-SQL DataContext here.   
}

Для вызова новых методов DAL и небольшой помощи DynamicLinq я использую:

int countryCount = Count(c => c.Country == country);
List<Customer> customers = Get(c => c.Country == country, "inserted", 0, 25);
int departmentCount = Count(c => c.Department == department);
List<Customer> customers = Get(c => c.Department == department, "inserted", 0, 25);

И все это до того, как вы начнете добавлять, обновлять и удалять, которые становятся однострочными вызовами с Linq2SQL! Мой DAL теперь состоит из 10 методов, где, как и раньше, было легко получить до 20-30 методов для каждого объекта, за которым следил мой DAL! Я настоятельно рекомендую попытаться разобраться в этом, так как это действительно сэкономит вам много кода.

Answer 2

LINQ-to-SQL в основном относится к DAL - это технология доступа к данным. Однако в достаточно простом приложении ничто не мешает вам передавать объекты, созданные LINQ, на бизнес-уровень и даже связывать их с вашим пользовательским интерфейсом. Почему нет?

Однако вы должны знать, что в этом случае вы довольно сильно привязываетесь к LINQ-to-SQL. Если это нормально для вашего сценария - отлично, используйте его! Это дизайнерское решение, которое вам нужно принять самостоятельно, в соответствии с потребностями вашего проекта.

Если система становится более сложной, особенно если ваши объекты LINQ, созданные из таблиц базы данных, не соответствуют 1: 1 вашим бизнес-объектам, вы всегда можете использовать бизнес-уровень для «сборки» реальных бизнес-объектов из ваших объектов LINQ. , С помощью такого инструмента, как AutoMapper , вы даже можете обойтись без написания большого количества назначаемых слева и справа кодов «обезьян»: -)

С другой стороны, если вы находитесь в такой ситуации, возможно, вы захотите взглянуть на ADO.NET Entity Framework, а не на LINQ-to-SQL. EF предоставляет вам множество этих более продвинутых функций, которые, вероятно, будут излишними для небольшого приложения, но могут быть абсолютно необходимыми для корпоративного приложения. Такие вещи, как поддержка нескольких поставщиков баз данных, такие как отображение ваших бизнес-объектов в другое физическое представление в вашей базе данных и т. Д.

Марк

Answer 3

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

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

Answer 4

Я написал простую телефонную книгу, используя linq и 3 слоя, вы можете скачать ее, и если у вас есть какие-либо вопросы по этому поводу, напишите мне бесплатно.

Доступен по адресу: http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=7597&lngWId=10

Answer 5

Я добавляю сущности в проект DAL и создаю репозиторий для доступа, который мне нужен. Если вы действительно не хотите, чтобы Linq to SQL объекты в BLL, вам нужно использовать технику двойного отображения. Использование шаблона хранилища позволяет легко издеваться над DAL.

Answer 6

LINQ не подходит для 3-х уровневой архитектуры. лучше всего подходит для двухуровневой архитектуры.

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

Поскольку объекты объектов LINQ работают в подключенной среде DataContext. так во время обновления и удаления логики. это дает ошибки.

Answer 7

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