Во время моего ученичества я использовал NHibernate для некоторых небольших проектов, которые я в основном кодировал и разработан сам по себе. Теперь, прежде чем начать какой-то более крупный проект, возникла дискуссия о том, как создать доступ к данным и использовать ли слой ORM или нет. Поскольку я все еще нахожусь в моем ученичестве и все еще считаю себя новичком в корпоративном программировании, я действительно не пытался подтолкнуть свое мнение, а это то, что использование объектного реляционного картографа в базу данных может значительно облегчить развитие. Другие кодеры в команде разработчиков гораздо более опытные, чем я, поэтому я думаю, что я просто буду делать то, что они говорят.: -)
Однако я не совсем понимаю две основные причины не использования NHibernate или аналогичного проекта:
- Можно просто создать собственные объекты доступа к данным с SQL-запросами и скопировать эти запросы из Microsoft SQL Server Management Studio.
- Отладка ORM может быть трудной.
Итак, я мог бы просто создать свой уровень доступа к данным с большим количеством SELECT
и т.д., но здесь я пропустил преимущество автоматических соединений, ленивых загрузочных прокси-классов и более низкого усилия по обслуживанию, если таблица получает новый столбец или столбец переименовываются. (Обновление многочисленных запросов SELECT
, INSERT
и UPDATE
против обновления конфигурации сопоставления и, возможно, реорганизации бизнес-классов и DTO.)
Кроме того, используя NHibernate, вы можете столкнуться с непредвиденными проблемами, если не знаете рамки очень хорошо. Это может быть, например, доверие к Table.hbm.xml, где вы устанавливаете длину строк, которая будет автоматически проверена. Тем не менее, я также могу представить похожие ошибки на "простом" уровне доступа к данным на основе SqlConnection.
Наконец, являются ли упомянутые выше аргументы действительно хорошей причиной, чтобы не использовать ORM для нетривиального приложения на базе базы данных? Возможно, есть другие аргументы, которые они/я мог пропустить?
(Возможно, я должен добавить, что это похоже на первое "большое" приложение на основе .NET/С#, которое потребует совместной работы. Хорошие практики, которые выглядят довольно нормально при переполнении стека, например, модульное тестирование или непрерывная интеграция, до сих пор не существуют.)