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

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

2 голосов
/ 24 октября 2008

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

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

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

Ответы [ 2 ]

5 голосов
/ 25 октября 2008

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

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

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

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

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

1 голос
/ 24 октября 2008

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

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

...