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

Question

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

На данный момент я разделил проекты на

Приложение.Просмотр - весь код, связанный с графическим интерфейсом
Приложение.Данные - только структуры данных и интерфейсы.Никакого другого кода реализации нет
Приложение.BusinessLogic - весь код бизнес-логики, который не имеет ссылок на графический интерфейс

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

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

Answer 1

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

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

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

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

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

Уровень доступа к данным

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

Деловой человек

Это включало бы любую бизнес-логику, включая проверку подлинности и безопасность.В 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, которая взаимодействует с базой данных (возможно, реализует шаблон репозитория).Сделав это, я бы разделил все следующим образом:

1. Приложение.Доступ к данным
2. Приложение.Доступ к данным
3. Приложение.Доступ к данным
4. Приложение.Модель
5. Приложение.BusinessLogic

Answer 3

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

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

Answer 4

1. -> Приложение.Данные
2. -> Приложение.Данные
3. -> App.BusinessLogic или App.Data - не уверен точно, что это значит.
4. -> Приложение.BusinessLogic
5. -> Приложение.BusinessLogic