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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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