Каков хороший подход для уровня доступа к данным?

Question

Наше программное обеспечение представляет собой специализированную систему управления человеческими ресурсами (HRMS), использующую ASP.NET с Oracle в качестве базы данных, и теперь мы фактически собираемся сделать ее продуктом, который поддерживает несколько арендаторов с собственными базами данных.

Наши опции:

1. Используйте NHibernate для поддержки нескольких баз данных и использования OO. Но мы беспокоимся о кривой обучения NHibernate и о любой проблеме, с которой мы столкнулись.

2. Создайте обобщенный DAL, который продолжит работу с Oracle, используя хранимые процедуры, и используйте инструменты для преобразования его в другие базы данных, такие как SQL Server или MySql. Существует риск, связанный с необходимостью поддержки нескольких зависящих от базы данных версий одного скрипта.

3. Предоставлять программное обеспечение как услугу (SaaS) и поддерживать то, как мы ведем бизнес. Однако могут быть клиенты, которые не хотят или не доверяют Cloud или другим бизнес-моделям SaaS.

Имея это в виду, какова лучшая техника уровня доступа к данным?

Answer 1

Я бы сказал, что NHibernate впечатляет на первый взгляд и кажется очень сложным в освоении. Поэтому после быстрого прочтения вступительного документа объемом около 260 страниц и настаивания на задачах, которые мне нужно было выполнить в тестовых приложениях, NHibernate - действительно путь. И если вы не очарованы файлами сопоставления XML, просто используйте FluentNHibernate , который позволяет использовать ООП для сопоставления объектов вашего бизнес-домена.

Более того, если вам не совсем удобно с NHibernate и вы предпочитаете идти другим путем, Enterprise Library 4.1 (октябрь 2008 г.) может оказаться полезным инструментом. В зависимости от ситуации в некоторых организациях я выбрал гибридный подход NHibernate - Enterprise Library. Блок приложения доступа к данным (DAAB) в Enterprise Library довольно прост в освоении и не требует от вас изучения ничего, кроме того, что вы уже знаете. Вам просто нужно знать, какой объект использовать для создания вашего DbConnection из класса DatabaseProviderFactory для чтения из ваших файлов конфигурации, и вы можете указать базу данных по умолчанию.

Что касается моих проблем, я часто использую как NHibernate, так и Enterprise Library. DAAB позволяет мне, например, указывать соединение с базой данных для каждого файла конфигурации, поскольку я предпочитаю указывать только одно соединение для каждого файла. Это позволяет мне не развертывать ненужные файлы конфигурации для конфигураций, которые вообще не менялись, а только развертывать новый файл конфигурации для другого соединения. Поэтому, если вы объединяете новый модуль, который должен подключаться где-то еще к другому хранилищу данных, вы собираете свой модуль, не заботясь об остальном, обновите свое программное обеспечение с помощью DLL вашего модуля вместе с этим новым файлом конфигурации DAAB.

Что касается NHibernate, важно не избавляться от ISessionFactory, когда он вам больше не нужен. Создание экземпляра обходится дорого, поэтому вы хотите сохранить его в памяти. Что вы можете сделать, так это сериализовать класс объектов конфигурации (так как он Serializable), так что ваше приложение может построить свою конфигурацию, только если что-то изменилось в вашем файле конфигурации NHibernate. С другой стороны, я предлагаю вам использовать файл конфигурации hibernate.cfg.xml по умолчанию для NHibernate, так что вам не нужно будет снова и снова развертывать файл app.config при появлении обновлений.

Надеюсь, это поможет! Дайте мне знать, если вам нужна дополнительная информация.

Answer 2

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

Я бы порекомендовал Nhibernate by Example, это отличная книга, чтобы помочь вам.

Answer 3

Я думаю, все зависит от приоритетов!

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

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

Answer 4

Я бы выбрал вариант № 3, поскольку он позволяет вам быстрее выйти на рынок и, как мы надеемся, обеспечит надежный поток доходов. Клиенты будут гораздо охотнее финансировать преобразование существующего успешного продукта в автономную систему, чем предлагаемый продукт. Вы также получите бесценные отзывы от реальных пользователей, которые улучшат продукт. И вы можете обнаружить, что на автономную систему нет спроса.

Если бы вы начинали с нуля, я бы предложил изучить NHibernate.

Answer 5

Использование NHibernate почти наверняка будет дешевле (как с точки зрения затрат на разработку, так и с точки зрения кривой обучения), чем пользовательский ORM для проекта любого значительного размера (более 20 таблиц?), Который должен поддерживать несколько поставщиков баз данных. Я не знаю, как ответить на пункт 3 в вашем списке, потому что я не знаю, как сравнить то, что вы делаете сегодня, с использованием NHibernate. Вполне возможно, что все, что вы делаете сегодня, на самом деле лучше, чем NHibernate, но вы не предоставили достаточно информации на этот счет. Это рискованное бизнес-решение - привязаться к конкретной бизнес-модели, основанной на технологическом решении, которое впоследствии может быть дорогостоящим, чтобы отменить его позже.

Answer 6

У нас был похожий сценарий «Поддержка HRM + ASP.NET + multi DB», и мы выбрали архитектуру dOOdads MyGeneration, и продукт уже выпущен и работает довольно хорошо!

просто Google для MyGeneration, и вы будете готовы к работе!

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