Абстрагирование слоев подключения к данным и уровней представления в корпоративном приложении

Question

Мы создаем корпоративное приложение, в которое мы будем включать несколько платформ для пользовательских интерфейсов (например, веб-приложение ASP.net, приложение Windows, а иногда и мобильные приложения) и несколько платформ для внутренних баз данных (например, SQL Server, XML, Oracle). Дополнительной необходимостью является то, что эти внутренние БД либо централизованы и доступны через Интернет, либо локализованы на клиентском компьютере и иногда синхронизируются с центральным сервером.

Кто-нибудь может дать совет о том, как мы можем абстрагировать слой пользовательского интерфейса & amp; уровень данных, чтобы мы могли проще создавать адаптивность и адаптивность между различными пользовательскими интерфейсами и различными вариантами выбора для БД? Например: в одном случае у нас может быть веб-приложение, работающее на централизованном сервере через Интернет, и у нас могут быть удаленные машины, на которых выполняются локализованные копии через приложение Windows. Через запланированные промежутки времени мы хотели бы, чтобы все машины были синхронизированы, чтобы они могли иметь данные почти в реальном времени.

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

Answer 1

Абстрагирование уровня представления является довольно простой концепцией, если вы знакомы с n-уровневой архитектурой. Просто сосредоточьтесь на различении «доменной логики» из "логики приложения". Логика домена распространена на разных платформах, а логика приложения зависит от платформы. Например, проверка данных - это логика домена (хотя хорошо, когда вы можете сделать это во внешнем интерфейсе, что усложняет задачу, но работает со мной здесь ...) и решение, какой URL перенаправить после какого-либо действия приложения логика. Убедитесь, что вы поставили свою доменную логику на уровень, который может использоваться любой платформой, и не ставьте какую-либо логику приложения на уровень вашего домена.

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

<Ол>

Надеюсь, ты не идешь на "Святой Грааль" независимости базы данных. Это всегда высокая цель, стоящая на этапе проектирования, которая почти всегда, почти каждый раз, не нужна.

Если это не то, к чему вы стремитесь, то я бы посоветовал вам знать, какие объекты хранятся в каком постоянном носителе, и вам следует избегать сложности гибкости и просто кодировать свои вертикальные пути как прямые переадресация, насколько это возможно. IE не кодирует лишние вещи в некоторый бизнес-класс, который хранит свои данные в Oracle, чтобы вы могли поместить их в SQL Server "в какой-то момент в будущем". (Я вернулся к независимости базы данных, не так ли?)

Вопрос локального кэширования данных для повышения производительности для определенных платформ является специфическим для этих платформ, и я бы посоветовал вам взглянуть на Smart Clients и структуру / руководство по кэшированию, которые есть у команды MS P & amp; P. Последние пару лет я работал исключительно над веб-материалами, но в 05/06 это было очень хорошо, и они тем временем много работали над своим умным клиентом.

Answer 2

Я бы посмотрел на использование модели провайдера для установления соединений с базой данных в вашем приложении.

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