Я работаю над веб-приложением .NET, которое использует базу данных SQL Server с приблизительно 20-30 таблицами. Большинство таблиц будут включены в .NET-решение как класс. Я написал свой собственный уровень доступа к данным, чтобы читать объекты и записывать их в базу данных. Все это состоит всего из нескольких классов, и очень немногие строки кода en используют generics и reflection, чтобы узнать, какие SQL и параметры использовать. Теперь это можно сделать, используя NHibernate (или схему similair), и некоторые сотрудники утверждают, что я глупо с моей стороны не использовать его. Мой главный аргумент в пользу того, что я не использую его, - это то, что я хочу получить максимальный контроль над своим приложением, точно знать, что все делает и как все работает, даже если это требует больше времени на разработку. Мне также не нравится факт, что мне нужно сопоставить мою базу данных в XML файлах (мое собственное решение позволяет мне отображать его в файлах сущности).
Итак, что бы я хотел услышать от вас, действительно ли глупо не использовать NHibernate в этой ситуации? Неужели я действительно незнаю или это не такая странная идея, чтобы использовать мое собственное решение?
Я думаю, что в наши дни на самом деле нет никаких оснований откатывать свою собственную систему персистентности, поскольку там так много хороших решений. Вам не нужно использовать NHibernate (хотя это хороший выбор), но я бы серьезно подумал о том, чтобы использовать что-то, что хорошо протестировано и установлено в отрасли, поскольку оно будет лучше работать и иметь меньше ошибок, чем то, что вы пишете сами.
Наверное, глупо писать собственные классы вместо использования NHibernate, но глупо продолжать использовать свои собственные классы, учитывая, что вы уже их написали. Может быть.
У вас есть несколько возможностей, которые, вероятно, лучше, чем вы изобретаете колесо. Позвольте мне назвать два наиболее вероятных варианта:
Используйте Entity Framework для DAL + DAO. Это сделает ваши классы (которые вы уже написали) устаревшими, поскольку EF будет создавать свои собственные, и вы будете в курсе последних языковых возможностей и технологий.
Используйте Fluent NHibernate, поэтому вам не нужно работать с XML-сопоставлениями. Таким образом, вы сохраните классы объектов бизнес-уровня, которые вы написали, и избегайте утомительных XML файлов NHibernation. Все это С#.
Ваш образ мышления хорош. Вы хотите контролировать. Это здорово. Но использование вашего собственного DAL в наши дни немного глупо, потому что вы в основном заново изобретаете колесо, плюс вы не будете тестировать/баггировать код, который займет немало времени для разработки + теста + отладки.
Если бы я был вами, я бы включил опцию # 2, так как я сделал вариант №1, и я знаю, что мне пришлось настраивать множество вещей, чтобы сделать работу EF так, как должна. EF будет готов с V2.
Я не буду называть вас глупым, потому что в прошлом я делал то же самое. Затем я начал использовать NHibernate и задавался вопросом, почему, черт возьми, я катался самостоятельно. Это хорошо, дайте ему идти.
Люди склонны использовать фреймворки, которые уже написаны, потому что, ну, они уже написаны (и протестированы).
Но есть заслуга в том, чтобы катиться самостоятельно. Только вы и ваши коллеги можете делать предположения о вашем домене. Общая структура, такая как NHibernate, не может делать много предположений, потому что это не сделает ее очень универсальной.
Когда вы сворачиваете свои собственные, вы можете испечь эти предположения в свою структуру, чтобы сделать более упорядоченный, естественный API. Тем не менее, если бы вы начали, я бы предложил использовать существующую структуру и обернуть ее, чтобы она соответствовала вашим потребностям. Но поскольку у вас уже есть что-то, и оно работает для вас, я не уверен, что предлагаю заменить его на что-то еще.
Это зависит от того, что они подразумевают под "глупым".
Если "глупыми" они означают, что вы не должны были писать свой персистирующий слой в первую очередь, они, вероятно, правы, но это плачет над пролитым молоком.
Если "глупо" означает, что вы должны переписать весь свой существующий код, чтобы использовать другую фреймворк (например, NHibernate), когда он уже работает с вашим, они, вероятно, ошибаются (хотя есть кое-что, что можно сказать о # ошибках в NHibernate против вероятных # ошибок в вашем).
Если "глупо" означает, что вся команда знает, что NHibernate холодна, и она уже используется в остальной части вашего кода, поэтому, используя вашу фреймворк, вы делаете это сложнее в команде, они абсолютно правы, и вы должны, вероятно, реорганизовать код в NHibernate как можно скорее, прежде чем какой-либо еще код будет заблокирован в вашей инфраструктуре.
Если "глупыми" они означают, что никто там действительно не знает NHibernate, они просто нравятся, тогда... никто не побеждает. Они суетливы, вы внедрили фреймворк, который вам не нужно... называть его галстуком.
Все сказанное говорит, что каждый должен написать структуру персистентности или три. Вероятно, они не должны попасть ни в какие корабли, но это хорошее упражнение. Единственная ошибка, которую вы сделали, это привязка кода, который команда должна была поддерживать в ваших хороших упражнениях.
Есть много хороших инструментов для сохранения, которые хорошо протестированы и имеют проверенную производительность (NHibernate, Linq для сущностей, LLBL Gen Pro). Если ваши потребности сильно отличаются от обычных структур постоянной сохранности, которые существуют, тогда я откажусь от своих собственных. Однако я хотел бы воспользоваться преимуществами тестирования и оптимизации существующего инструмента, если это вообще возможно.
Сказав это, я также мог бы опрокинуть свои собственные, если бы захотел создать собственный инструмент ORM и был готов жить с минусами (не так хорошо проверены или оптимизированы, как инструменты, которые были вокруг в течение многих лет, скорость выхода на рынок).
Создавая свое собственное решение, особенно когда оно работает нормально, и быть таким простым, как вы говорите, не является ни невежественным, ни странным. Существует множество ситуаций, когда лучше сделать это, чем добавлять зависимость от отдельного проекта, такого как nHibernate.
Тем не менее, есть, конечно, также много ситуаций, когда полная противоположность истинна.:)
Это действительно зависит от вашего проекта и команды. Если вы разрабатываете корпоративное приложение, которое в конечном итоге будет поддерживаться кем-то другим, придерживаться отраслевых стандартов может быть хорошей идеей, даже если это означает немного больше работы вперед.
Все ответы здесь замечательные, но я действительно удивлен, что никто не упомянул Castle ActiveRecord, он звучит очень похоже на то, что ваш framework делает и действительно упрощает интерфейс для NHibernate. Это один из шаблонов, которые сделали Ruby on Rails настолько популярными в конце концов!
Айенде Рахиен (один из главных разработчиков NH) дал несколько лет назад большую презентацию ActiveRecord в Оредеве, которую я очень рекомендую: http://www.viddler.com/explore/oredev/videos/89
Я думаю, что это вопрос баланса сил. Вы говорите, что хотите контролировать, и вам не нужны сопоставления. Если этот контроль стоит за счет увеличения затрат на разработку и обслуживание, а для создания рабочего кода требуется больше времени, то это проблема.
Я лично не вижу проблемы при перетаскивании структуры, если она упрощает повторяющуюся задачу и делает разработку более продуктивной и более стабильной в кодах из-за меньшего пространства для интерпретации. Мы включили нашу собственную структуру, которая включает реализацию сохранения/доступа к данным. Однако наши причины для этого были конкретными. В этом случае он должен был работать в среде DDD, которая была намного ближе к тому, что описывает Эванс, чем то, что предоставляет большинство продуктов на полке.
Я думаю, что разница в том, что мы понимаем, что есть первоначальная стоимость и что она в конечном итоге будет сбалансирована благодаря экономии времени разработки в будущем. Конечно, если вы пишете код, который вам нужно вручную управлять соединениями, картографировать данные и т.д., Вы, вероятно, идете по неправильному пути. По крайней мере, вы можете использовать что-то вроде Enterprise Library, чтобы помочь вам справиться с утомительным подключением и построением команд. Но, я также думаю, что если у вас нет повторного использования - ничего, что является "фреймворком" типа реализации, которое вы можете абстрагироваться и применять к другим проектам, то вы создаете кошмар обслуживания и время, которое вы будете единственным владельцем из.
Мы также использовали наши собственные классы доступа к данным и классы сущностей. У нас также был генератор кода, который использовал для создания всех этих классов для нас. Но теперь мы используем Entity Framework, и мы более чем счастливы.
Простой совет: Начните изучать nHibernate или что хотите и начнете использовать его в своем следующем проекте.
Пространства сущностей - http://www.entityspaces.net/Portal/Default.aspx
также является хорошим инструментом.
Я закончил использование Fluent NHibernate для работы. Все мои классы сущностей были созданы с помощью ActiveRecordGenerator (http://code.google.com/p/active-record-gen/)