Який консенсус щодо того, коли використовувати один із цих інструментів, який рекламується для іншого? Я вважаю Subsonic дуже корисним з точки зору швидкого виконання робіт, але у великих проектах він, як правило, не масштабується, і пов’язує вашу модель домену з моделлю бази даних. Саме тут входить Nhibernate, оскільки він дає вам легкі POCO, які не пов’язані з вашою моделлю бази даних, але час налаштування значно довший.
Відповіді:
Мені дуже часто задають це питання, і насправді це зводиться до того, наскільки ти хочеш возитися. Я не можу сказати вам, наскільки шкідливими були коментарі Кріса Сайваса RE SubSonic масштабування - і з тих пір я відповідаю на них :(.
Угода така - ідеально підходить, SubSonic дуже гарно масштабується. З точки зору зростання проекту - БУДЬ-який інструмент, який ви використовуєте, вимагатиме вашої уваги. Навіть NHibernate.
Я написав допис про те, як використовувати шаблон сховища з DI (як і у випадку з NHIb або будь-яким іншим інструментом) з SubSonic 2.1:
http://blog.wekeroad.com/blog/subsonic-writing-decoupled-testable-code-with-subsonic-2-1/
Я також написав допис про виступ SubSOnic:
http://blog.wekeroad.com/blog/subsonic-scaling/
Сподіваюся, це допомагає.
Я б рекомендував SubSonic, якщо ваш проект працює з поданням ActiveRecord, що база даних є вашою моделлю. Ви отримаєте один клас на стіл, і все просто магічно працює. Ви, звичайно, можете налаштувати і замінити речі, але якщо ви (або ваш проект) принципово не згодні з підходом клас-за-таблицею, я б подивився на NHibernate, оскільки він починається з більш складного (але більш гнучкого) підходу картографування вашого модель домену до вашої бази даних.
Якщо ви використовуєте відносно просту базу даних, яка знаходиться під вашим контролем (як, наприклад, ви можете змінювати стовпці, не надсилаючи вісім форм до комісії з контролю за підрозділом баз даних), я б рекомендував почати з SubSonic і перейти до NHibernate, якщо SubSonic цього не зробить задовольнити ваші потреби.
Чого це варте ... Я мав можливість використовувати обидві технології набагато більше, відколи поставив це питання. І я мушу залишитися, що, якщо ці технології ви вибираєте, має значення дуже мало. Звичайно, NHibernate дозволяє вашим суб’єктам господарювання бути дещо менш пов’язаними зі структурою вашої бази даних, але я все одно виявляю, що є багато випадків, коли вам все одно доводиться прихилятися до волі бази даних.
На мій погляд, єдиним вірним способом, щоб повністю відокремити вашу модель домену від вашої моделі бази даних, є написання власного DTOS (по суті POCO для передачі даних навколо), а потім відображення їх назад до вибраного вами ORM на рівні даних. Але в більшості випадків такий підхід спричинить для мене більше клопоту, ніж варто.
Трохи не в темі, але схожим чином. Ви заглядали в Castle ActiveRecord, він написаний поверх NHibernate і усуває необхідність витрачати час на створення XML-зіставлення з коду в базу даних. Як і NHibernate, ви можете структурувати об'єкти домену як завгодно, а згодом генерувати схему бази даних з цієї структури.
За допомогою ActiveWriter , внесеного інструменту, ви можете легко зіставити зі своєї бази даних об’єкти домену.
Ви можете поглянути на вільний NHibernate; це робить управління NHibernate бризом. Не впевнені, наскільки важко було б перенести існуючу схему, але якщо ви створюєте нову програму, приємно визначити модель домену та сформувати базу даних майже на будь-якому сервері БД, про який ви можете подумати. Читаючи інші коментарі тут, я думаю, що Fluent NHibernate зрівняє NHibernate з SubSonic для зручності конфігурації.
Я не можу дати хорошого порівняння, оскільки я ще фактично не використовував NHibernate у проекті, але я використовував SubSonic і був дуже задоволений цим. Поки що я не зазнав жодних серйозних перешкод при його використанні.
Ознайомтесь із цим дописом від Роб Конері, одного із творців SubSonic. Він розповідає про те, як відокремити ваш код SubSonic від решти програми. Він навіть згадує той факт, що ця архітектура дозволить згодом замінити SubSonic на якийсь інший рівень доступу до даних, такий як NHibernate або LINQ на SQL.
Я знаю, що насправді не відповів на ваше запитання, але, сподіваюся, це все одно допоможе.
Нещодавно я писав допис у блозі про .NET ORM, в яких є Subsonic та ActiveRecord. З мого досвіду, це залежить від того, що робить проект, Subsonic працює набагато краще, якщо ви походите з SQL-середовища, але NHibernate має більше цього. ActiveRecord підходить для менших проектів, я не впевнений, що для більших проектів це швидше, ніж дотримання NHibernate.
Я оцінив обидва, і я вважаю, що було б несправедливо рекомендувати одне над іншим, не розуміючи, які ваші цілі. У своєму питанні ви добре зазначили відмінності, і я вважаю, що це має бути вашим вирішальним фактором. Особисто я використовував і те, і інше і надалі, залежно від проекту.
Знову ж трохи не по темі, але я віддам Castle ActiveRecord - замість того, щоб використовувати базу даних як свою модель (підзвуковий підхід) або витрачати години в XML-спагетті (підхід NHibernate), ви просто розміщуєте атрибути на своїх класах моделей.
Ви навіть можете отримати ActiveRecord для створення схеми бази даних для вас.
Ми використовували цей підхід у багатьох проектах зараз, і переваги полягають у наступному:
Думаю, ти це майже прибив. Subsonic генерує код, тому ваші бізнес-об'єкти відображатимуть структуру вашої бази даних. nHibernate використовує файли зіставлення, які відображають ваші бізнес-об'єкти в базі даних, щоб ваші об'єкти могли бути структуровані як завгодно.
Наскільки це великий проект? Чи буде потрібна довгострокова підтримка? Чи економічна ефективність Subsonic компенсує будь-які потенційні проблеми масштабування?
Ми завантажуємось дозвуком і зараз намагаємося оцінити, чи збираємося ми переходити до нібернації тепер, коли ми знаходимось в болючих точках дозвуку.
Нашим іншим варіантом є створення середньої точки, де ми використовуємо дозвукову інформацію для запиту та завантаження довільних об’єктів з їх функціональністю «виконувати як набраний список», яка виконує відображення на основі імені довільного оператора sqq стилю linq. Або спробувати відтворити частину з них у нібібернаті, а реструктурувати решту.
Тому я кажу, що дозвуковий сенс має сенс у невеликих програмах, але обслуговування дозвукових додатків стає досить волохатим, у нас особливо важкі часи з перекриваючим кодом перевірки та подіями, ініційованими до / після в коді. Для активного шаблону запису дозвуковий рівень, безумовно, становить 80%, але щось робить нестабільно і заважає вам мати реальний контроль над ієрархією успадкування, оскільки кожен клас повинен успадкувати таблицю, щоб повернутися до цієї таблиці.
Враховуючи розмір вашої команди та проекту, розглядаючи ActiveRecord.
З мого досвіду, ActiveRecord - це абстракція поверх NHibernate, яка починає просочуватися, як решето, при спробі більш складних сценаріїв.
Якщо у вас є поміркована до дуже складна або непроста схема, дотримуйтесь NHibernate. Ви можете нарізати і нарізати кубиками майже до досконалості.
Інше місце, де ви можете потрапити в біду, - коли вам потрібен помірно складний запит. ActiveRecord приховує багато реалізацій NHibernate ... але вам він знадобиться для складного запиту, який стане дуже складним, якщо ви зовсім не знайомі з HQL. Будьте обережні, члени команди не просто рубають краї, замість того, щоб вивчати NHibernate та HQL.
Прийміть невідповідність імпедансу!
:)
Або ні. Якщо ви хочете виступу, зробіть це самостійно. Якщо ви хочете зробити це швидко і легко, використовуйте NHibernate та ActiveRecord. Якщо вам подобається робити вигляд, що ви насправді знаєте, що відбувається на рівні доступу до даних, використовуйте NHibernate і сидіть із XML цілий день, щоб змусити багатьох до багатьох ... Або просто ... помилка .. зробіть це самостійно - ADO.Net FTW!
Я вважаю, що вам слід дотримуватися тієї, яку ви можете використати найкраще. Кінцевою метою є продуктивність та якісний код якості. Якщо ви знаєте SubSonic всередині і поза, тоді дотримуйтесь його, і якщо ви знаєте NHibernate поглиблено, дотримуйтесь NHibernate. Це дуже суб'єктивне питання. Ви також повинні врахувати той факт, що члени вашої команди мають досвід. Якщо ви добре це вмієте, ви зможете це легко підтримувати.
Я бачив великі проекти з використанням SubSonic, тоді як NHibernate вже відомий і широко використовується.
Рішення щодо вибору ORM залежить не тільки від самого ORM.
Порада, яку я отримав по цій темі, полягає в тому, що Subsonic не масштабується для обробки більш складних сценаріїв, і тому, якщо ви підете цим шляхом, у вас з’явиться робота, яка намагатиметься перейти на більш просунуту ORM.
Таким чином, я більше зацікавлений у використанні NHibernate для складних випадків, Castle Active Record для більш простих випадків, і я стежу за Fluent NHibernate, що має набагато спростити картографування NHibernate (особливо після вдосконалення підтримки картографування на основі конвенції).