Можно ли использовать Linq-to-Sql? - PullRequest
9 голосов
/ 13 мая 2011

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

NHibernate, Небольшое промежуточное ПО, Overkill

Там, где я работаю, мы теперь почти исключительно используем NHibernate для истинной доменной разработки.

Я работаю над небольшим временным (срок службы, вероятно, год, может быть, меньше) компонентом промежуточного программного обеспечения, где NHibernate чувствует себя немного излишним с точки зрения конфигурации и поддержания сущностей в актуальном состоянии. Тем более, что я не имею никакого контроля над БД, она иногда меняется, и это немного «наследие».

Недавно в БД были внесены некоторые изменения, и сопоставления NHibernate не очень полны.

Linq к Sql? Или EF?

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

RAD But Dead?

В этом сценарии RAD-элементы Linq-to-Sql имеют смысл. Но это по сути старая технология. Я не должен использовать это? Я никогда не использовал Entity Framework. Должен ли я использовать это, это так же просто и быстро использовать?

ура

Ответы [ 3 ]

6 голосов
/ 13 мая 2011

Можно ли по-прежнему использовать Linq-to-sql?

Да.Можно использовать любую технологию, которая позволяет вам доставить продукт вовремя, с необходимой функциональностью и качеством.Вы все еще можете найти проекты, используя ASP, ADO, VB6.Одна из причин, по которой технологиям Microsoft приходится очень тяжело во многих международных корпорациях, заключается в том, что их продукты имеют очень короткий срок службы.Linq-to-sql был на рынке менее 2 лет и был признан устаревшим Microsoft, но компании / сообщества спорили об этом, и Microsoft немного изменила свою стратегию.Linq-to-sql не имеет новых функций, но он все еще поддерживается и является полностью функциональной технологией.

Решит ли Linq-to-sql или EF ваши проблемы?

Это зависит.Возможно да и возможно нет.Не верьте маркетинговым объявлениям о RAD.Иногда мне кажется, что люди думают, что RAD - это дизайнер. Нет .Инструменты, поддерживающие RAD, представляют собой четко определенный API, который прост для понимания, прост в использовании и не содержит неожиданного поведения ( Принцип наименьшего удивления ) - вы будете использовать API для быстрого создания прототипа приложения, но оно все равнотребует понимания и практики.Отображение NHibernate все еще является прототипом, когда вы сравниваете его с ручным доступом к данным.Мы можем даже следовать основному правилу хорошей структуры: простые вещи легко сделать, а сложные возможны.Это то, что NHibernate делает намного лучше, чем EF или Linq-to-sql.

Если вы знаете NHibernate, но у вас нет реального опыта работы с EF или Linq-to-sql, вы можете быть уверенычто ни Linq-to-sql, ни EF не повысят вашу производительность в первом или двух проектах, где вы его используете.Если у вас нет большого опыта с переходом NHibernate на EF или Linq-to-sql, вероятно, это не приведет к временной потере производительности.

Я также не думаю, что EF или Linq-to-sql, как правило, помогут вам в ситуациях, когда изменяется база данных.Как я помню, в Linq-to-sql конструкторе вообще нет функциональности отображения обновлений, и поэтому он очень часто используется полностью без дизайнера, поэтому вам все равно придется вручную изменять отображение.Модель обновления EF из базы данных может быть полезна здесь, но это не серебряная пуля.Некоторые обновления могут потребовать ручного изменения файла EDMX (огромный XML).

Наконец, имейте в виду, что функции сопоставления NHibernate гораздо более эффективны, особенно при работе с устаревшими базами данных.Функции отображения Linq-to-sql очень ограничены, в большинстве случаев это отображение таблиц в классы 1: 1 с некоторыми исключениями (базовое наследование TPH).EF предлагает более сложные функции отображения, но он каким-то образом ожидает правильного проектирования базы данных.

2 голосов
/ 13 мая 2011

Хорошее обсуждение NHibernate против L2S / EF

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

2 голосов
/ 13 мая 2011

Если вам (и вашим коллегам) удобно с NHibernate, то он должен быть таким же быстрым, как Linq to SQL.Нет никаких причин не использовать L2S, если вы понимаете, что Microsoft не получит значительных обновлений и улучшений, но по моему опыту, если вы уже знаете, как использовать обе платформы, нет необходимости заново выполнять работу.только потому, что L2S может быть немного больше RAD

...