Нужен совет по выбору метода доступа к данным

Question

Я нахожусь на ранних этапах планирования преобразования большого классического приложения базы данных ASP в ASP.Net, и у меня возникают проблемы с выбором метода доступа к данным. Я поиграл с Linq To SQL, динамическими данными, строго типизированными наборами данных, корпоративной библиотекой (блоки приложений доступа к данным) и чуть-чуть с Entity Framework, но ни один из них не выскочил мне как «один». Есть слишком много вариантов - моя голова плавает, помогите мне выбрать!

Возможно, это поможет дать некоторое представление о приложении, которое я конвертирую, наряду с приоритетами ...

• Серверной частью является Microsoft SQL Server (2005 или более поздняя версия), и мы привержены этому, поэтому мне не нужно беспокоиться о том, чтобы когда-либо поддерживать другую платформу базы данных.

• База данных очень зрелая и содержит много бизнес-логики. Он очень нормализован и широко использует хранимые процедуры, триггеры и представления. Я бы предпочел не изобретать два колеса одновременно, поэтому я хотел бы внести как можно меньше изменений в базу данных. Итак, мне нужно выбрать метод доступа к данным, который достаточно гибок, чтобы позволить мне обойти любые причуды в базе данных.

• Приложение имеет множество форм ввода данных и широкие возможности поиска и отчетности (отчеты - еще одно чудовище, о котором я расскажу позже).

• Приложение должно быть достаточно гибким, чтобы справляться с незначительными изменениями в структуре базы данных. Приложение (и база данных) могут быть установлены на разных сайтах, где в базу данных вносятся незначительные пользовательские изменения. В идеале приложение может идентифицировать расширения базы данных и реагировать соответствующим образом. Другими словами, если мне нужно сохранить отображение O / R в приложении, я должен иметь возможность поменять его (или легко обновить) при установке приложения и базы данных на новом сайте.

• Быстрая разработка приложений имеет решающее значение. Поскольку база данных уже готова, а пользовательский интерфейс будет тесно соответствовать существующему приложению, я надеюсь найти что-то, где мы сможем справиться с этим довольно быстро. Я готов пожертвовать не использованием новейших и самых совершенных технологий, если это сэкономит время на разработку. Другими словами, если есть крутая кривая обучения использованию чего-то вроде Entity Framework, я вполне подхожу для использования чего-то вроде строго типизированных наборов данных и пользовательского DAL, если это ускорит процесс.

• Я новичок в ASP.Net, но хорошо знаком с классическим ASP, T-SQL и старым ADO (например, отключенные наборы записей). Если какой-либо из методов доступа к данным лучше подходит для кого-то из моего происхождения, я могу склониться в этом направлении.

Спасибо за любой совет, который вы можете предложить!

Answer 1

Посмотрите на все три статьи в этой серии:

Высокопроизводительная архитектура уровня доступа к данным, часть 1

Отличный совет.

Answer 2

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

Используя внедрение зависимостей, вы можете использовать xml, чтобы сообщить платформе, какой конкретный класс использовать для интерфейса.

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

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

Для нового приложения, над которым я работаю, я начинаю с LINQ to SQL, главным образом потому, что разработка будет быстрее, но позже, если я решу, что это не будет соответствовать моим потребностям, я просто заменю его.

Answer 3

nHibernate может подойти. Вы можете сохранить отображение во внешних конфигурационных файлах, которые будут соответствовать вашим потребностям. Другой вариант может использовать ActiveRecord , основанный на nHibernate.

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