Сейчас идет жаркая дискуссия по поводу новой Microsoft.Data.dll. В двух словах: она позволяет делать примерно то же, что SqlDataReader - сделать SQL запрос с параметрами, получить массив строк. Но при этом писать ещё меньше кода.
Меня поражает, что в этом споре слышны всего два аргумента. Фанаты design patters и ORM ругают Microsoft за то, что они поддерживают плохой стиль программирования. Сотрудники Microsoft (в том числе такие видные, как Martin Fowler и Scott Gu) вяло оправдываются: "Да, мы знаем что мы сделали гавно для программистов-любителей, но в мире есть куча лохов, которые по-прежнему пишут SQL вручную, и с этим всё равно надо что-то делать".
Я как считаю, что Microsoft выпустила неплохую штуку для профессиональных программистов, а не для любителей. Когда мы говорим о преимуществах ORM, то надо чётко разделять два вида задач: чтение и модификация данных. Когда у тебя сложная база данных с сотнями миллионов записей и требуется высокая скорость чтения, то на сегодняшний день никакой ORM не даст такой производительности, как хранимая процедура или вручную написанный запрос. Например потому, что из-за динамического добавления одного параметра в WHERE может полностью поменяться план запроса.
Если говорить о модификации данных, то да, тут ORM может быть очень удобен. Ну, например, у тебя 100 полей в записи, ты изменил только одно, и Entity Framework может честно включить только одно, а не сто полей в UPDATE. Или он может помочь разрешать конфликты. Но, кстати, для bulk update может понадобиться написать хранимую процедуру. Да, это часто приводить к дублированию кода, но зато и скорость работы может подскочить в сотни раз. Конечно, ещё раз повторюсь, много зависит от задачи. Одно дело - банковская система, где одна ошибка может стоить миллионы; другое дело - read-only веб-сайт с большим количеством посетителей.
И ещё одна поразительная вещь: никто не говорит о том, что, на самом деле, Microsoft.Data.dll и Domain Model прекрасно могут существовать вместе. Если ты сделал SELECT * FROM Product, немедленно получил автоматически сгенерированный объект продукт, то использовать его во всех местах программы - это действительно плохой стиль. Но я так делать не собираюсь. Я буду работать с классом ProductModel, а динамический класс Product буду вручную переводить в ProductModel.
3 комментария:
чета ты накрутил и я толком не понял. Но моя точка зрения такая. Пока нет ничего подходящего для "набрасывания" кода, его приходится писать вручную. Хотя да, очень странно, что кроме подсветки синтаксиса, ничего глобального не придумали (либо я не видел)
Почитай, например, вот это: http://weblogs.asp.net/davidfowler/archive/2010/08/02/introduction-to-microsoft-data-dll.aspx
Смысл простой: как перевести запрос в массив .NET-объектов, и при этом писать поменьше строк кода. Ничего революционного нет, просто экономия времени, и смотрится код красивее.
Иногда, Майкрософт делает "многообещающие" вещи, например, Entity Framework.
Дабы не быть лохом (по словам Гу), который весь код для SQLLite пишет вручную, я решил использовать связку Entity Framework (LINQ to Entity) и SQLLite (через стандартного DbProviderFactory).
На беглое изучение потребовался день, на разбор бесконечной вереницы ошибок - три дня.
Как выяснилось, в такой связке работает только инструкция выборки данных. Все остальные действия (добавления, обнов. и удаления) - сплошные недоработки и ошибки.
В итоге, пришлось писать руками.
P.S. При привязке провайдера MS SQL ("родного", что называется...) - всё работает идеально.
Отправить комментарий