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

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

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

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

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

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

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

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

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

просто поищите в Google MyGeneration, и все будет готово!

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

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

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

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

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

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

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