Не глупо ли я использовать NHibernate для моего проекта?

Question

Я работаю над веб-приложением .NET, которое использует базу данных SQL Server с приблизительно 20-30 таблицами. Большинство таблиц будут включены в .NET-решение как класс. Я написал свой собственный уровень доступа к данным, чтобы прочитать объекты и записать их в базу данных. Все это состоит всего из нескольких классов, и очень немногие строки кода en используют generics и reflection, чтобы узнать, какие SQL и параметры использовать. Теперь такая вещь может быть выполнена с использованием NHibernate (или рамки similair), и некоторые сотрудники утверждают, что я глупо с моей стороны не использовать его. Мой главный аргумент в пользу того, что я не использую его, - это то, что я хочу получить максимальный контроль над своим приложением, точно знать, что все делает и как все работает, даже если это стоит мне больше времени разработки. Мне также не нравится факт, что мне нужно сопоставить мою базу данных в XML-файлах (мое собственное решение позволяет мне отображать его в файлах сущностей класса).

Итак, что я хотел бы услышать от вас, действительно ли глупо не использовать NHibernate в этой ситуации? Я действительно незнаю или это не такая странная идея, чтобы использовать мое собственное решение?

Answer 1

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

Answer 2

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

Answer 3

Люди склонны использовать фреймворки, которые уже написаны, потому что они уже написаны (и протестированы).

Но есть заслуга в том, чтобы кататься самостоятельно. Только вы и ваши коллеги можете делать предположения о вашем домене. Общая структура, такая как NHibernate, не может делать много предположений, потому что это не сделает ее очень универсальной.

Когда вы катитесь самостоятельно, вы можете испечь эти предположения в своей структуре, чтобы сделать более упорядоченный, естественный API. Тем не менее, если бы вы начали, я бы предложил использовать существующую структуру и обернуть ее, чтобы она соответствовала вашим потребностям. Но поскольку у вас уже есть что-то, и это работает для вас, я не уверен, что предлагаю заменить его на что-то еще.

Answer 4

У вас есть несколько возможностей, которые, вероятно, лучше, чем вы изобретаете колесо. Позвольте мне назвать два наиболее вероятных варианта:

1. Используйте Entity Framework для DAL + DAO. Это сделает ваши классы (которые вы уже написали) устаревшими, поскольку EF будет создавать свои собственные, и вы будете в курсе последних языковых возможностей и технологий.

2. Fluent NHibernate, так что вам не нужно работать с XML-сопоставлениями. Таким образом, вы сохраните классы объектов бизнес-уровня, которые вы написали, и избегайте утомительных XML-файлов NHibernation. Это все C#.

Ваш образ мышления - это хорошо. Вы хотите контролировать. Хорошо.Но использование вашего собственного DAL в наши дни немного глупо, потому что вы в основном изобретаете колесо, плюс у вас не будет проверенного/багги кода, который займет немало времени для разработки + теста + отладки.

Если бы я был вами, я бы выбрал вариант № 2, так как я сделал вариант №1, и я знаю, что мне пришлось настраивать множество вещей, чтобы работа EF работала так, как должна. EF будет готов с V2.

Answer 5

Я не буду называть вас глупым, потому что я сделал то же самое в прошлом. Затем я начал использовать NHibernate и задавался вопросом, почему, черт возьми, я катался самостоятельно. Это хорошо, отпустите его.

Answer 6

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

Я лично не вижу проблемы при перетаскивании рамки, если она упрощает повторяющуюся задачу и делает разработку более продуктивной, а код более стабильной из-за меньшего пространства для интерпретации. Мы включили нашу собственную структуру, которая включает реализацию сохранения/доступа к данным. Однако наши причины для этого были конкретными. В этом случае он должен был работать в среде DDD, которая была намного ближе к тому, что описывает Эванс, чем то, что предоставляет большинство продуктов на полке.

Я считаю, что разница заключается в том, что мы понимаем, что есть первоначальная стоимость и что она в конечном итоге будет сбалансирована благодаря экономии времени разработки в будущем. Конечно, если вы пишете код, который вам нужно вручную управлять соединениями, картографировать данные и т. Д., Вы, вероятно, идете по неправильному пути. По крайней мере, вы можете использовать что-то вроде Enterprise Library, чтобы помочь вам справиться с утомительным подключением и построением команд. Но, я также думаю, что если у вас нет повторного использования - ничего, что является «фреймворком» типа реализации, которое вы можете абстрагироваться и применять к другим проектам, то вы создаете кошмар обслуживания и время, которое вы будете единственным владельцем из.

Answer 7

Есть много хороших инструментов для обеспечения устойчивости, которые хорошо протестированы и имеют проверенную производительность (NHibernate, Linq для объектов, LLBL Gen Pro). Если ваши потребности сильно отличаются от обычных структур постоянной сохранности, которые существуют, тогда я откажусь от своих собственных. Однако я хотел бы воспользоваться преимуществами тестирования и оптимизации существующего инструмента, если это вообще возможно.

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

Answer 8

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

Это, конечно, также есть множество ситуаций, когда полная противоположность истинна. :)

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

Answer 9

Все ответы здесь замечательные, но я очень удивлен, что никто не упомянул Castle ActiveRecord, это звучит очень похоже на то, что делает ваш фреймворк и действительно упрощает интерфейс для NHibernate. Это один из шаблонов, которые сделали Ruby on Rails настолько популярными в конце концов!

Ayende Rahien (один из главных разработчиков NH) дал большое представление о ActiveRecord в Oredev несколько лет назад, которые я настоятельно рекомендую: http://www.viddler.com/explore/oredev/videos/89

Answer 10

Мы также используем наши собственный уровень доступа к данным и объектные классы. У нас также был генератор кода, который использовал для создания всех этих классов для нас. Но теперь мы используем Entity Framework, и мы более чем счастливы.

Простой совет: Начните изучать nHibernate или что хотите и начнете использовать его в своем следующем проекте.

Answer 11

Это зависит от того, что они подразумевают под «глупостью».

Если «глупо» означает, что вы не должны были писать свой персистирующий слой в первую очередь, они, вероятно, правы, но это плачет о пролитом молоке.

Если «глупые» означают, что вы должны переписать весь существующий код, чтобы использовать другой фреймворк (например, NHibernate), когда он уже работает с вашим, они, вероятно, ошибаются (хотя есть кое-что, что можно сказать о # ошибках в NHibernate против вероятных # ошибок в вашем).

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

Если «глупыми» они означают, что никто, действительно, не знает NHibernate, они просто нравятся, тогда ... никто не побеждает. Они суетливы, вы внедрили фреймворк, который вам не нужно ... назовем его галстуком.

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

Answer 12

Entity Spaces - http://www.entityspaces.net/Portal/Default.aspx

также является хорошим инструментом.

Answer 13

В результате я использовал Fluent NHibernate для работы. Все мои классы сущностей были созданы с помощью ActiveRecordGenerator (http://code.google.com/p/active-record-gen/)