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