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

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

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

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

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

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

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

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

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

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

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

It depends on what they mean by "foolish."

If by "foolish" they mean you shouldn't have written your persistence layer in the first place, they're probably right, but that's crying over spilled milk.

If by "foolish" they mean you should rewrite all your existing code to use another framework (like NHibernate) when it's already working with yours, they're probably wrong (although there's something to be said for # of bugs in NHibernate vs likely # of bugs in yours).

If by "foolish" they mean the entire team knows NHibernate cold, and it's already used in the rest of your code, so by using your framework you're making it harder on the team, they're absolutely right, and you should probably refactor the code in NHibernate as soon as possible, before any more code gets locked in to your framework.

If by "foolish" they mean no one there really knows NHibernate, they just like it, then... nobody wins. They're being fussy, you implemented a framework you didn't have to... let's call it a tie.

All of that said, everyone should write a persistence framework or three. Those probably shouldn't end up in anything that ships, but it's a good exercise. The only mistake you made was tying code the team had to maintain into your good exercise.

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

Айенде Рахиен (один из основных разработчиков NH) несколько лет назад провела ВЕЛИКОЛЕПНУЮ презентацию ActiveRecord в Oredev, которую я настоятельно рекомендую: http://www.viddler.com/explore/oredev/videos/89

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

Тем не менее, конечно, также существует множество ситуаций, когда верно и обратное. :)

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

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

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

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

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

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

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

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

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

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

Пространства сущностей - http://www.entityspaces.net/Portal/Default.aspx

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

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