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

Question

У меня есть существующее веб-приложение, в котором есть слой данных и bll, который вызывает слой данных. Уровень данных - ado.net, который вызывает хранимые процедуры.

Я создал другой проект в vs.net для linq-to-sql, перетянул все свои таблицы.

Было бы разумно просто начать использовать linq, или я должен потратить время и переписать всю логику БД в linq, чтобы у меня не было проблем с двумя слоями данных!

Answer 1

Если это не сломано, не исправляйте это.

Почему вы хотите полностью переписать свой идеально работающий слой данных? ADO.NET + хранимые процедуры - отличный выбор. Оставь это. В то же время вы можете начать играть с LINQ.

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

Мое предложение состоит в том, чтобы получить некоторый опыт работы с ним отдельно и не начинать переписывать все полностью только потому, что LINQ - это круто.

Answer 2

Пожалуйста, поясните: между Linq и LinqToSql есть существенная разница. Linq великолепен, и вы должны использовать его, если это вообще возможно. LinqToSql не велик и имеет много проблем:

Не используйте Visual Studio 2008 LinqToSql O / R Designer

Недостатки принятия Linq To Sql

Чтобы использовать Linq, вам понадобится ORM . У вас есть много вариантов для ORM в мире .NET. Если вам нравится то, что предлагает LinqToSql, вам может быть наиболее удобно использовать SubSonic . В долгосрочной перспективе NHibernate является лучшим выбором для .NET ORM прямо сейчас. Я написал намного больше о выборе .NET ORM здесь:

.NET и ORM - Решения, решения

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

Кроме того, вот убедительная статья против использования хранимых процедур:

Хранимые процедуры плохие, хорошо?

Answer 3

Если ваш текущий уровень данных по какой-то причине не сломан, не просто начинайте внедрять новый, просто потому, что вы можете.

Хотя, если в настоящее время уровень данных состоит из использования хранимых процедур, и это становится громоздким в обслуживании, переключение на L2S (или любое другое OR / M в этом отношении) может быть действительной причиной. Только не думайте, что вам нужно будет просто перетащить несколько столбцов на холст. Зависимый, если в sprocs есть какая-либо логика, логика должна где-то существовать ...

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