Мне бы хотелось, чтобы сообщество приняло некоторые мысли о Linq to Sql и других средствах отображения ORM.
Мне нравится Linq to Sql и идея выражать логику доступа к данным (или операциям CRUD в целом) на вашем родном языке разработки, а не иметь дело с "несоответствием импеданса" между C # и SQL. Например, чтобы вернуть ObjectDataSource-совместимый список экземпляров Event для бизнес-уровня, мы используем:
return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })
Если бы я реализовал это с использованием старых конструкций SQL-to-C #, мне пришлось бы создать класс Command, добавить параметр EventID (используя строку для описания аргумента "@EventID"), добавить запрос SQL введите строку в класс Command, выполните команду и затем используйте (cast-type) nwReader ["FieldName"], чтобы получить каждое возвращенное значение поля и назначить его члену вновь созданного экземпляра моего класса EventData (yuck).
Итак, , что - вот почему людям нравится Linq / SubSonic / и т.д. и я согласен.
Однако на более широкой картине я вижу ряд вещей, которые не верны. Я чувствую, что Microsoft также видит что-то не так, и именно поэтому они убивают Linq для SQL и пытаются перевести людей в Linq для Entities. Только я думаю, что Microsoft удваивает ставку из-за плохой ставки.
Так, что не так?
Проблема в том, что есть астронавтов архитектуры , особенно в Microsoft, которые смотрят на Linq to Sql и понимают, что это не настоящий инструмент управления данными: есть еще много вещей, которые вы не можете легко сделать из Комфортно в C # и они стремятся исправить это. Вы видите это в амбициях Linq to Entities, сообщениях в блоге о революционной природе Linq и даже в LinqPad вызов .
И проблема с в том, что заключается в том, что он предполагает, что SQL является проблемой. То есть, чтобы уменьшить легкий дискомфорт (несоответствие импеданса между SQL и C #), Microsoft предложила эквивалент скафандра (полная изоляция), когда пластырь (Linq to SQL или что-то подобное) вполне подойдет.
Насколько я вижу, разработчики достаточно умны, чтобы освоить реляционную модель и затем разумно применять ее в своих усилиях по разработке. На самом деле, я бы пошел еще дальше и сказал, что Linq to SQL, SubSonic и т. Д. уже слишком сложны: кривая обучения не так уж сильно отличается от освоения самого SQL. Поскольку в обозримом будущем разработчики должны осваивать SQL и реляционную модель, мы столкнулись с изучением двух языков запросов / CRUD. Хуже того, Linq часто сложно протестировать (у вас нет окна запроса), он удаляет нас на один уровень из реальной работы, которую мы выполняем (генерирует SQL), и имеет очень неуклюжую поддержку (в лучшем случае) для таких конструкций SQL, как Обработка даты (например, DateDiff), «Имея» и даже «Группировать по».
Какая альтернатива? Лично мне не нужна другая модель доступа к данным, как Linq to Entities. Я бы предпочел просто открыть окно в Visual Studio, ввести и проверить мой SQL, а затем нажать кнопку, чтобы сгенерировать или дополнить класс C # для инкапсуляции вызова. Поскольку вы уже знаете SQL, не хотели бы вы просто ввести что-то вроде этого:
Select EventID, Title From Events Where Location=@Location
и в результате получается класс EventData, который A) содержит поля EventID и Title в качестве свойств, а B) имеет метод фабрики, который принимает строку «Location» в качестве аргумента и генерирует список ? Вы должны тщательно продумать объектную модель (приведенный выше пример, очевидно, не справляется с этим), но фундаментальный подход, основанный на использовании SQL и устранении несоответствия импедансов, очень меня привлекает.
Вопрос: я ошибаюсь? Должна ли Microsoft переписать инфраструктуру SQL, чтобы вам больше не приходилось изучать управление SQL / реляционными данными? Могут ли переписать инфраструктуру SQL таким образом? Или вы думаете, что очень тонкий слой поверх SQL, чтобы избавить вас от необходимости настройки параметров и доступа к полям данных, вполне достаточен?
Обновление Я хотел продвинуть две ссылки на вершину, потому что я думаю, что они отражают важные аспекты того, что я преследую. Во-первых, CodeMonkey указывает на статью под названием «Вьетнам компьютерных наук». Требуется некоторое время, чтобы начать, но это очень интересное чтение. Во-вторых, AnSGri указывает на одну из наиболее выдающихся пьес Джоэла Спольски: Закон Утечки Абстракций . Это не совсем по теме, но это близко и является отличным чтением.
Обновление 2: я дал «ответ» ocdecio, хотя здесь есть много хороших ответов, и выбор «правильного» ответа является чисто субъективным. В этом случае его ответ в квадрате с тем, что я считаю действительно лучшей практикой, учитывая современное состояние технологий. Однако это та область, в которой я полностью ожидаю развития, поэтому все может измениться. Я хотел бы поблагодарить всех, кто внес свой вклад, я проголосовал за всех, кто, я думаю, дал вдумчивый ответ.