Хорошая архитектура для 2-уровневого настольного приложения (клиент-сервер) с помощью linq-to-sql
Наша существующая архитектура - UI, BusinessLayer, DAL (генерировал linq-to-sql).In уровень DAL, мы добавили логику проверки для объектов в частичном классе. Мы непосредственно используем объекты, сгенерированные linq-to-sql в businesslayer (который является набором классов - class\form).Also, в этих bll классах, мы создаем linq к запросам SQL.
Я чувствую, что мы могли разделить приложение на уровни лучше с точки зрения шаблона MVP и иметь классы обслуживания, которые обеспечивают данные с помощью linq-to-sql. Что Вы думаете? Я должен рассмотреть шаблон репозитория? Это было бы излишеством?
4 ответа
Это хорошая идея!
Ваш выбор зависит от вашего приложения, но здесь много проблем:
1) Преобразование между объектной моделью базы данных и объектной моделью приложения может быть намного сложнее. В таких случаях невозможно реализовать фильтры в модели для приложения, чтобы полученный запрос можно было передать в SQL.
2) Часто в результате выборки необходимо получить результат соединения (JOIN) нескольких таблиц, а не только данные из одной таблицы
3) Не все SQL-операции и функции имеют свои эквиваленты в LINQ
А как насчет Entity Framework? Пожалуйста, не трогайте Entity Framework. Это тяжелая и медленная вещь! :)
Я предпочитаю классический доступ к данным через хранимую процедуру и доступ к данным из MS Enterprise Library. Я могу использовать мощь и гибкость SQL в моих собственных бизнес-объектах. И конечно - спектакль! Оборотная сторона медали - больше работы. Я использовал некоторые инструменты для автоматического создания объектов доступа к данным, а затем исправлял их по мере необходимости.
Удачи!
Все хорошее, о чем стоит подумать, но, когда вы начнете идти по этому пути, я уверен, что в большинстве случаев у вас будет больше вопросов, чем ответов!
Я предполагаю, что вы используете Windows Forms, когда упоминаете Desktop и Linq-To-SQL, что создаст вам несколько проблем при реализации чего-то вроде шаблона MVP.
Несмотря на то, что для WinForms существуют предварительно настроенные инфраструктуры MVP (на ум приходит MVC #), если вы не разрабатываете крупномасштабные приложения, вы можете начать осторожно и реализовать некоторые концепции, используя свой собственный код.
Превосходная серия статей Джереми Миллера Build Your Own CAB - отличный ресурс здесь, так как вы можете извлечь некоторые из первых идей и получить некоторое разделение проблем между вашими формами (презентация) и бизнес-логика (Presenters и Service классы).
Джереми в своей работе использует в основном дизайн контролирующего контроллера (который мне очень нравится), но стоит взглянуть на другие шаблоны, такие как Passive View и Model-View-ViewModel (который встроен в способ работы WPF, поэтому стоит понять ), чтобы увидеть, что вам удобнее всего.
Что касается вашего вопроса о классах обслуживания или репозиториях, я бы подумал, что основными двумя уровнями логики, которые вам нужны, являются объекты Presenter или ViewModel, а затем объекты Service ниже того, которые могут содержать такие вещи, как ваш Linq-To-SQL. запросы. Таким образом, у вас, возможно, уже есть большая часть логики для вашего уровня сервиса, но это скорее случай его рефакторинга в согласованную форму.
Разработчикам может быть сложно понять MVP, но вы можете попробовать.
Похоже, вы на правильном пути. Если у вас есть уровень службы WCF, вы можете запускать его в процессе или через HTTP, что означает, что вы можете поддерживать приложение типа клиент-сервер, а не обращаться к БД из внешнего интерфейса, но это действительно зависит от вашего приложения.