Структурирование решения Winforms C #

Question

Так что я реорганизую решение winforms C #, чтобы помочь отделить его и сделать его более чистым и организованным. Решение отслеживает заказы малого бизнеса и т. Д. .

Я разбил проекты на

App.View - весь код, связанный с графическим интерфейсом
App.Data - просто структуры данных и интерфейсы. Нет другого кода реализации
App.BusinessLogic - весь код бизнес-логики, не имеющий ссылок на графический интерфейс

У меня есть несколько классов, которые я не могу понять, где они принадлежат. Пожалуйста, дайте мне знать, что вы думаете о том, какой проект должен пройти каждый класс, или если есть другой проект, который должен быть создан для этого.

1. Класс, который извлекает пользовательские настройки из базы данных
2. Класс, который получает статические данные с нашего сервера статических данных и возвращает наборы результатов данных.
3. Класс, который снижает права пользователя
4. Модельный класс, в котором хранится хэш-таблица заказов
5. Класс, отправляющий сообщения о действиях пользователя по электронной почте

Answer 1

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

С этой точки зрения все, что извлекает или приносит, обязательно будет находиться на вашем уровне данных - это доступ к данным в постоянном хранилище. То, что он извлекает, в итоге преобразуется в объекты бизнес-уровня, на которых работает ваша бизнес-логика. Это концептуальные модели - например, таблица заказов - или бизнес-действия относятся к бизнес-уровню. Я бы согласился с @Adron, возможно, с той же путаницей в отношении того, где (3) идет в зависимости от того, что на самом деле.

Более конкретно:

1. Предпочтения пользователя - бизнес объекты, вещь, которая извлекает это объект уровня данных.
2. Статические данные отображаются на бизнес объект (таблица или вид или что-то), вещь, которая получает доступ к внешнему Сервер является объектом уровня данных.
3. Пользовательское право - это бизнес-объект, а то, что его извлекает, - это объект уровня данных.
4. Таблица заказов - это бизнес-объект
5. Работа с электронной почтой - это бизнес, поэтому почтовые сообщения - это бизнес-объект

[РЕДАКТИРОВАТЬ] Моя обобщенная 3-уровневая архитектура для (простых) веб-приложений

DataAccessLayer

Это будет включать мои TableAdapters и строго типизированные DataTables и Factories, которые превращают строки моих DataTables в бизнес-объекты в проектах до LINQ. При использовании LINQ это будет включать мой DataContext и сгенерированные дизайнером сущности LINQ.

BusinessLayer

Это будет включать в себя любую бизнес-логику, включая проверку и безопасность. В pre-LINQ это были мои бизнес-объекты и любые другие классы, которые реализуют логику приложения. Используя LINQ, это частичные реализации классов моих сущностей LINQ для реализации безопасности и проверки наряду с любыми другими классами для реализации бизнес-логики.

Презентация

Это мои веб-формы - в основном пользовательский интерфейс приложения. Я включаю некоторые из проверочной логики в формы в качестве оптимизации, хотя они также проверяются в BL. Это также включает любые пользовательские элементы управления.

Примечание: Это логическая структура. Структура проекта, как правило, отражает это, но в некоторых случаях, например, при подключении к веб-службам, они могут быть непосредственно включены в веб-проект, даже если компоненты действительно находятся в BL / DAL.

Примечание: Я, вероятно, перейду на MVC через 3 уровня, как только ASP.NET MVC будет запущен. Я сделал несколько личных проектов в Ruby / Rails, и мне действительно нравится парадигма MVC для веб-приложений.

Answer 2

Вы указали, что App.Data должен содержать только структуры данных и интерфейсы, без кода реализации, что хорошо, если вы хотите это сделать, но в этом случае вам некуда поместить код доступа к вашей базе данных, кроме как в вашем App.BusinessLogic. сборка.

Возможно, вам действительно нужно переименовать App.Data в App.Model (или что-то подобное), и иметь новую сборку App.DataAccess, которая взаимодействует с базой данных (возможно, реализует шаблон Repository). Сделав это, я бы разделил вещи так:

1. App.DataAccess
2. App.DataAccess
3. App.DataAccess
4. App.Model
5. App.BusinessLogic

Answer 3

1. -> App.Data
2. -> App.Data
3. -> App.BusinessLogic или App.Data - точно не знаю, что это значит.
4. -> App.BusinessLogic
5. -> App.BusinessLogic

Answer 4

Я бы, наверное, пошел с

1. Данные
2. Данные
3. Данные, хотя я не совсем уверен, что делает класс
4. Данные
5. BusinessLogic