Как решить правильный шаблон разработки для клиентского приложения.NET, которое в конечном счете совместно использует код с веб-приложением?
Я плохо знаком с шаблонами разработки, но я очень старался реализовать некоторых в прошлом году. Я запустил в новой организации, и весь код содержался в форме. Так как я добрался здесь, я пытался использовать подход MVC для нашей.NET 2,0 приложения.
Другие разработчики начали видеть потребность в этом подходе, и мы достигаем точки, где мы хотим согласовать шаблон разработки, за которым мы будем все следовать. И в то время как я пытался учиться, я не уверен, что знаю, который шаблон является лучшим для реализации. Вот некоторые наши конструктивные ограничения:
- Клиентское приложение с локальными данными, хранившими в базе данных Access, которая синхронизируется к Базе данных Oracle (должен поддерживать разъединенных пользователей),
- Функциональность клиентского приложения будет также доступна сети в наступающем году
- .NET 2,0 среды, которые будут перемещаться в 3,5 или 4.o в следующем году
Сообщите мне, есть ли у Вас другие вопросы.Я признателен за Вашу помощь.
Спасибо!
2 ответа
Это наглядный пример того, для чего используется сервисный уровень -:
(Статья с более подробным описанием различных уровней)
Вы можете придерживаться своей MVC архитектуры, но теперь контроллер обращается к вашему сервисному уровню (отдельному проекту библиотеки классов в вашем решении), для любых методов бизнес-логики. Он расположен поверх домена и репозитория и позволяет вам выполнять связанные с бизнесом действия между любыми проектами, используя сервисный уровень.
Таким образом, ваши бизнес-правила не будут распределены по всему контроллеру, а ваш контроллер останется выполнять свою работу: извлекать и организовывать данные для передачи в представление.
Таким образом, вы можете иметь ваше клиентское приложение и ваше веб-приложение и ссылаться на один и тот же проект сервисного уровня, и делиться между ними кодом бизнес-логики.
.Я думаю, что здесь лучше всего использовать многоуровневый подход. Я бы начал с нижнего уровня доступа к данным (DAL), используя Entity Framework или NHibernate. Затем вы можете поставить слой бизнес-логики поверх него, а затем поставить сервисный слой поверх него. При этом и ваши windows и веб приложения могут использовать каждый из этих уровней по мере того, как он включается. Я читаю Microsoft .NET: Architecting Applications for the Enterprise от Dino Esposito прямо сейчас, и это очень полезно с этими типами проблем.
Вот диаграмма того, о чем я говорю:
