Структурирование решения winforms на C #
-
03-07-2019 - |
Вопрос
Итак, я реорганизую решение winforms C #, чтобы помочь отделить его и сделать более чистым и организованным.Решение отслеживает заказы малого бизнеса и т.д..
На данный момент я разделил проекты на
Приложение.Просмотр - весь код, связанный с графическим интерфейсом
Приложение.Данные - только структуры данных и интерфейсы.Никакого другого кода реализации нет
Приложение.BusinessLogic - весь код бизнес-логики, который не имеет ссылок на графический интерфейс
У меня есть несколько классов, которые я не могу понять, к чему они относятся.Пожалуйста, дайте мне знать ваши соображения о том, в какой проект должен пойти каждый класс, или есть ли другой проект, который должен быть создан для этого.
- Класс, который извлекает пользовательские настройки из базы данных
- Класс, который извлекает статические данные с нашего сервера статических данных и возвращает наборы результатов данных.
- Класс, который снижает права пользователя
- Класс модели, в котором хранится хэш-таблица заказов
- Класс, который отправляет по электронной почте сообщения о действиях пользователя
Решение
На самом деле, я думаю, что у вас есть вещи, немного отличающиеся от традиционной многоуровневой архитектуры.Обычно модели ваших данных, с которыми работает ваше приложение, хранятся на бизнес-уровне вместе с кодом для работы с ними.Ваш уровень данных будет содержать как модели данных вашей платформы сохранения, так и код для взаимодействия с этой платформой.Я думаю, что это может быть источником путаницы между предлагаемыми местами проведения ваших занятий и вашей реакцией на это, основанной на ваших комментариях.
С этой точки зрения все, что извлекается или переносится, обязательно должно быть расположено на вашем уровне данных - это доступ к данным в постоянном хранилище.То, что он извлекает, в конечном итоге преобразуется в объекты бизнес-уровня, с которыми работает ваша бизнес-логика.Вещи - это концептуальные модели, такие как таблица заказов, или бизнес-действия, относящиеся к бизнес-уровню.Я бы согласился с @Adron, возможно, с такой же путаницей в отношении того, куда девается (3), в зависимости от того, что это на самом деле.
Более конкретно:
- Пользовательские настройки - это бизнес-объекты то, что извлекает их, является объектом уровня данных.
- Статические данные отображаются на бизнес объект (таблицу, представление или что-то еще), объект, который обращается к внешнему серверу, является объектом уровня данных.
- Права пользователя - это бизнес-объект, то, что его извлекает, - это объект уровня данных.
- Таблица заказов - это бизнес-объект
- Отправка электронной почты - это бизнес-активность, поэтому то, что отправляет письма людям, является бизнес-объектом
[РЕДАКТИРОВАТЬ] Моя обобщенная 3-уровневая архитектура для (простых) веб-приложений
Уровень доступа к данным
Это включало бы мои адаптеры таблиц и строго типизированные таблицы данных и фабрики, которые превращают строки моих таблиц данных в бизнес-объекты в проектах до LINQ.Используя LINQ, это включало бы мой DataContext и объекты LINQ, созданные дизайнером.
Деловой человек
Это включало бы любую бизнес-логику, включая проверку подлинности и безопасность.В pre-LINQ это были бы мои бизнес-объекты и любые другие классы, которые реализуют логику приложения.Используя LINQ, это частичные реализации классов моих объектов LINQ для реализации безопасности и проверки наряду с любыми другими классами для реализации бизнес-логики.
Презентация
Это мои веб-формы - по сути, пользовательский интерфейс приложения.Я включаю некоторую логику проверки в формы в качестве оптимизации, хотя они также проверяются в BL.Это также будет включать любые пользовательские элементы управления.
Примечание: Это логическая структура.Структура проекта обычно отражает это, но есть некоторые случаи, такие как подключения к веб-службам, которые могут быть непосредственно включены в веб-проект, даже если логически компоненты действительно находятся в BL / DAL.
Примечание: Я, вероятно, буду двигаться в MVC более 3-х раз ASP.NET MVC-это в производстве.Я выполнил несколько личных проектов на Ruby / Rails, и мне действительно нравится парадигма MVC для веб-приложений.
Другие советы
Вы указали, что App.Data должен содержать только структуры данных и интерфейсы, никакого кода реализации, что прекрасно, если вы хотите это сделать, но в результате вам некуда будет поместить код доступа к базе данных, кроме как в вашу сборку App.BusinessLogic.
Возможно, вам действительно нужно переименовать App.Data в App.Model (или что-то подобное) и создать новую сборку App.DataAccess, которая взаимодействует с базой данных (возможно, реализует шаблон репозитория).Сделав это, я бы разделил все следующим образом:
- Приложение.Доступ к данным
- Приложение.Доступ к данным
- Приложение.Доступ к данным
- Приложение.Модель
- Приложение.BusinessLogic
Я бы, наверное, пошел с
- Данные
- Данные
- Данные, хотя я не совсем уверен, что делает класс
- Данные
- Бизнес-логика
- -> Приложение.Данные
- -> Приложение.Данные
- -> App.BusinessLogic или App.Data - не уверен точно, что это значит.
- -> Приложение.BusinessLogic
- -> Приложение.BusinessLogic