Архитектурное проектирование DAL слоя

Question

Я работаю по архитектуре середины размера веб-приложения & для моего DAL слоя я имею 3 варианта

1) Традиционные ХП Based Architecture (Использование NTiers Шаблон CodeSmith)

2) LINQ To SQL (или PLINQO Шаблон CodeSmith)

3) LINQ To Entity

с выше LINQ к Сущности находится вне досягаемости, как нам нужно, чтобы запустить приложение очень быстро, и мы не имеем suffi для этого и команда никогда не работала над любыми инструментами OR/M, это будет крутая кривая обучения для них (это то, что я читал где-то)

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

Теперь моя проблема заключается в том, что я должен использовать linq для sql или должен придерживаться традиционной архитектуры?

ИЛИ еще какой-нибудь другой вариант есть ...

EDIT: Я собираюсь использовать SQL Server в качестве базы данных и не требует, чтобы взаимодействовать с любой другой базы данных

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

Кроме того, если вы чувствуете, что любой инструмент ORM действительно хорошо и не имеет крутой кривой обучения, то и мы можем использовать

Просьба представить предложения

Answer 1

Как вы работаете в проекте среднего размера, я хотел бы предложить вам использовать LINQ-TO-SQL из-за этих преимуществ

Преимущества использования LINQ к SQL:

• Нет волшебных строк, как у вас есть в SQL запросов • Intellisense • Compile проверить, когда база данных изменений • Более быстрое развитие • Единица работы шаблона (контекст) • Auto-порожденных объектов предметной области, которые могут использоваться небольшие проекты • Ленивая загрузка. • Обучение написанию запросов linq/lambdas - это обязательное обучение для разработчиков .NET. Что касается производительности:

• Скорее всего, производительность не будет проблемой в большинстве решений. Предварительная оптимизация - это анти-шаблон. Если позже вы заметите, что некоторые области приложения замедлятся, вы можете проанализировать эти части, а в некоторых случаях даже обменять некоторые запросы linq с помощью хранимых процедур или ADO.NET. • Во многих случаях функция ленивой загрузки может ускорить работу или, по крайней мере, упростить код. Относительно отладки:

• На мой взгляд, отладка Linq2Sql намного проще, чем хранимые процедуры и ADO.NET. Я рекомендую вам взглянуть на Linq2Sql Debug Visualizer, который позволяет вам видеть запрос и даже запускать выполнение, чтобы увидеть результат при отладке. • Можно также настроить контекст для записи всех SQL запросов в окне консоли, больше информации здесь Что касается другого слоя:

• Linq2Sql можно рассматривать как еще один слой, но это чисто уровень доступа к данным. Хранимые процедуры также являются еще одним слоем кода, и я видел много случаев, когда часть бизнес-логики была внедрена в хранимые процедуры. Это гораздо хуже, на мой взгляд, потому что вы затем разделяете бизнес-уровень на два места, и разработчикам будет сложнее получить четкое представление о бизнес-домене.

Answer 2

Там нет абсолютно Предпочитаемый способ написания DAL. Это все варианты. Какой из них выбрать, зависит от вашего проекта, ваших навыков и ваших склонностей.

Как правило, с LINQ вы можете ожидать более продуктивной работы. С другой стороны, можно ожидать, что DAL, построенный с помощью хранимых процедур, будет работать быстрее.

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

Что касается поддержки LINQ to SQL и дальнейшей разработки, она уже давно была основана. Так что никакого официального дальнейшего развития. Примечание: это верно для реляционного решения LINQ to SQL (оно будет рассмотрено EF), а не для основных функций LINQ.

Entity Framework в своем v.1 только получил массовые критики. Вам рекомендуется подождать, пока не выйдет v2.

Наиболее важным ограничением с LINQ (над Entity Framework или любым другим популярным ORM) является то, что он не поддерживает от 1 до n сопоставлений. То есть каждый ваш класс LINQ может отображать только одну таблицу, а не представлять какой-то вид над несколькими другими. Возможно, это не важно для вас, но, возможно, это так. Зависит от вашего проекта.

Answer 3

С ограничениями упомянуть, я бы сказал, просто придерживайтесь adhoc/custom запросов и ADO.NET, а не для каких-либо джазовых вещей. Кроме того, DAL с хранимой процедурой быстрее - это основанные на концепции хронические аргументы, такие как хранимые процедуры, предварительно скомпилированные, но они не являются. Все, что у них есть, это кеш плана запроса. Чем меньше инвестиции в хранимые процедуры, тем лучше. Мой совет ADO.Net и пользовательские динамические запросы, созданные из объектов сущностей.

Answer 4

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

Answer 5

Аргумент хранимых процедур против ORM давно и вряд ли будет разрешен в ближайшее время. Моя рекомендация состояла бы в том, чтобы пойти с ORM (Linq-to-Sql в вашем случае).

Да, хранимые процедуры всегда будут быстрее, поскольку запросы предварительно скомпилированы. Реальный вопрос, который вы должны задать себе, заключается в том, есть ли у вас такая высокопроизводительная система, что ваши пользователи действительно заметят разницу. Имейте в виду, что использование хранимых процедур означает, что вам нужно будет вручную написать все свои собственные запросы, где использование ORM сделает это за вас. Это обычно означает, что ORM ускорит ваше развитие.

Поскольку вы упоминаете, что ускорение разработки является одной из ваших целей, я бы порекомендовал Linq-to-Sql - иначе вы в основном напишите весь DAL самостоятельно.

Answer 6

Все варианты, которые вы предоставили, имеют существенные недостатки. Ни один из них не отвечает требованиям, которые вы указали.

Вам необходимо определить приоритетность того, что для вас наиболее важно.

Если кривая обучения является ваш большой проблемой, держаться подальше от всех ORMs, если вы уже знакомы с ADO.NET, DataTables и т.д.

Если скорость развития ваша самая большая проблема, вы должны научиться ОРМ и идти этот маршрут. Самый простой ORM, рекомендуемый для NHibernate. Все остальные ОРМ имеют значительные недостатки. NHibernate работает в подавляющем большинстве проектов, тогда как другие ORM гораздо более ситуативно подходят (в зависимости от вашего дизайна БД, дизайна модели, требований гибкости, поддержки устаревшей схемы и т. Д.). Все ОРМ имеют кривые обучения, они просто вступают в игру в разное время и по-разному.