Мне действительно нужен ORM?

Question

Мы собираемся начать разработку на веб-сайте ASP.Net MVC 2 среднего размера. Для типичной страницы мы берем данные и подбрасываем их на веб-странице, то есть не требуется много предварительной обработки данных перед их отправкой в ​​пользовательский интерфейс.

Сейчас мы принимаем решение, использовать ORM или нет, и если да, то какой. Мы рассматривали EF2 AKA EF4 (ASP.Net Entity Framework в VS 2010) как одну из возможностей.

Тем не менее, я думаю, что простым решением в этом случае может быть просто использование таблиц данных. Причина в том, что мы не планируем перемещать данные или обрабатывать их многократно после их извлечения, поэтому я не уверен, что наличие строго типизированных объектов в качестве DTO имеет такую ​​большую ценность. Кроме того, таким образом мы полностью исключаем отображение, поэтому я думаю, что упростить код и ускорить разработку.

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

Мы еще не полностью решили это, но в настоящее время склоняемся к отсутствию ORM. Удастся ли нам использовать подход без ORM или стоит ORM?

Answer 1

ORM-инструмент не обязателен!

Совет Джона разумен, но я думаю, что использование DataTables не идеально.

Если вы используете инструмент ORM, объектная модель намного проще, чем полноценная модель предметной области. Более того, Linq2Sql и Subsonic , например, просты в использовании. Возможность очень быстрого изменения кода при изменении базы данных.

Вы говорите, что не будете перемещать данные или обрабатывать их много, но любой объем обработки будет гораздо проще в объектах ORM, чем в DataTables. Опять же, если приложение изменяется и требуется дополнительная обработка, решение DataTable будет хрупким.

Answer 2

Если вы не собираетесь практиковать полномасштабное объектно-ориентированное программирование (и под этим я подразумеваю, что у вас должно быть очень глубокое понимание ООП, а не только умение выпаливать принципы и имена шаблонов проектирования), тогда НЕТ, это не стоит идти на ОРМ.

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

Если стиль программирования вашей команды / организации всегда был склонен к сохранению бизнес-логики в БД (например, хранимых процедур) или придерживался более или менее функционального / процедурного / статического подхода при написании объектов и методов, покончите с ORM и придерживаться ADO.NET.

Answer 3

Если у вас уже есть хранимые процедуры, в которых вы нуждаетесь, то, вероятно, не так уж много от ORM. Если нет, хотя мой опыт показывает, что работа с Linq для Entites была намного быстрее, чем традиционный подход к хранимым процедурам / строго типизированным наборам данных, предполагая, что вы знакомы с запросами Linq.

Если вы не беспокоитесь о сопоставлении с объектной моделью, тогда Linq to SQL еще проще в использовании. Вам, конечно, не нужно использовать полную ОО-модель, чтобы воспользоваться преимуществами производительности.

Было бы несогласным с точкой зрения Малкольма о необходимости возврата графиков. Если ORM поддерживает Linq, вы можете использовать проекцию для возврата плоского результата только с теми данными, которые вам нужны, с дополнительным преимуществом, что запрос обычно проще, чем соответствующий SQL так как вы можете использовать отношения, а не присоединиться.

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

Answer 4

Звучит так, как будто вам нужно только показать данные и не делать CRUD.

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

SQL-оператор намного лучше в этом. Я все еще возвращал бы списки строго типизированных объектов из DAL. Таким образом, у вас больше шансов получить ошибку времени компиляции, когда изменение DAL не отражается в других слоях.

Answer 5

Это во многом зависит от того, насколько вы знакомы с ОРМ.

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

Тем не менее, есть крутая кривая обучения, особенно если вы пытаетесь делать что-то не хакерским способом (что вам следует), так что, если ваша команда не имеет опыта здесь, а время требует времени, то, вероятно, не будет сокращать это.

Linq2SQL слишком прост. Не знаю о Subsonic, но если вы собираетесь использовать ORM, это может быть хорошим балансом между быстрой разработкой и получением чего-то слишком мощного и сложного.

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

Answer 6

Я согласен с советом Джо Р. - за скорость внесения изменений, а также за скорость первоначальной разработки, LINQ-to-SQL или дозвуковая система поднимет вас и заработает в кратчайшие сроки.

Если ваше приложение действительно такое простое и представляет собой просто прямые данные / данные в прямом сопоставлении с таблицами, вы рассматривали возможность просмотра ASP.net динамических данных ?

Я бы также указал на хорошую статью об этом Скотта Гатри.