Хорошая архитектура для 2-уровневого (клиент-серверного) настольного приложения с использованием linq-to-sql

Question

Наша нынешняя архитектура - пользовательский интерфейс, BusinessLayer, DAL (сгенерированный linq-to-sql). На уровне DAL мы добавили логику проверки для сущностей в частичном классе. Мы напрямую используем сущности, сгенерированные linq-to-sql в businesslayer (который является связкой классов - class \ form). Также в этих классах bll мы создаем запросы linq-to-sql.

Я чувствую, что мы могли бы лучше наложить слой приложения с точки зрения шаблона MVP и иметь классы обслуживания которые предоставляют данные, используя linq-to-sql. Как вы думаете? Должен ли я рассмотреть шаблон хранилища? Будет ли это излишним?

Answer 1

MVP может быть сложно понять разработчикам, но вы можете попробовать.

Answer 2

Все хорошие вещи, о которых стоит подумать, но когда вы начнете идти по этому пути, я уверен, что у вас будет больше вопросов, чем ответов в большинстве случаев!

Я предполагаю, что вы используете Windows Forms, когда упоминаете Desktop и Linq-To-SQL, что даст вам несколько проблем при реализации чего-либо, например шаблона MVP.

Несмотря на то, что существуют предварительно адаптированные MVP-структуры для WinForms (MVC # приходит на ум), если вы не разрабатываете крупномасштабные приложения, вы можете начать осторожно и реализовать некоторые концепции, используя свой собственный код.

Превосходная серия статей Джереми Миллера Build Your Own CAB - отличный ресурс, поскольку вы можете взять некоторые из первых нескольких идей и получить некоторое разделение проблем между вашими формами (презентация) и бизнес-логика (ведущие и классы обслуживания).

Джереми использует в своей работе главным образом дизайн Supervising Controller (который мне нравится), но стоит взглянуть на другие шаблоны, такие как Passive View и Model-View-ViewModel (которые встроены в способ работы WPF, поэтому стоит разобраться ), чтобы увидеть, что вам наиболее удобно.

Что касается вашего вопроса о классах обслуживания или репозиториях, я бы подумал, что вам понадобятся два основных уровня логики - сущности Presenter или ViewModel, а затем сущности Service ниже уровня, который может содержать такие вещи, как ваш Linq-To-SQL. запросы. Таким образом, вы, возможно, уже имеете большую часть логики для своего уровня Service, но это скорее случай его преобразования в согласованную форму.

Answer 3

Это хорошая идея!

Ваш выбор зависит от вашего приложения, но это много проблем:

1) Преобразование между моделью объектной базы данных и приложением объектной модели может быть намного сложнее. В таких случаях невозможно реализовать фильтры на модели для приложения, чтобы результирующий запрос мог быть передан в SQL.

2) Часто в результате выборки необходимо получить результат соединения (JOIN) нескольких таблиц, а не только данные из одной таблицы

3) Не все SQL-операции и функции имеют свой эквивалент в LINQ

А как насчет Entity Framework? Пожалуйста, не трогайте Entity Framework. Это тяжелая и медленная вещь! :)

Я предпочитаю классический доступ к данным через хранимые процедуры и доступ к данным из MS Enterprise Library. Я могу использовать мощь SQL и гибкость своих собственных бизнес-структур. И конечно же - производительность! Обратная сторона медали - больше работы. Я использовал некоторые инструменты для автоматического создания объектов доступа к данным, а затем исправлял их по мере необходимости.

Удача!

Answer 4

Звучит так, как будто вы на правильном пути. Если у вас был сервисный уровень WCF, вы могли бы запустить его в процессе или через HTTP, что означает, что вы могли бы поддерживать приложение типа клиент-сервер, а не работать с БД из внешнего интерфейса, но это действительно зависит от вашего приложения.