Проблема технического дизайна: должна ли она быть на уровне DAL, Business или ViewModel? - PullRequest
Новая
       30

Проблема технического дизайна: должна ли она быть на уровне DAL, Business или ViewModel?

0 голосов
/ 17 февраля 2020

Я занимаюсь разработкой простого приложения для отслеживания расходов, упорядоченного по категориям, в C# и структуре сущностей.

Мои сущности:

Категория: Id, Имя Расход: Id, Имя, дата, CategoryId

Я использую MVVM и разделяю проблемы: у меня есть бизнес-уровень, уровень доступа к данным и уровень модели представления / представления.

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

Где мне интегрировать расчет этих сумм для каждой категории? Q1: На моем бизнес-уровне мой объект категории имеет поле "SummedExpensesAmmount", поэтому я подумал, что из моего бизнес-уровня я буду вызывать DAL, чтобы заполнить это поле для каждой категории и в течение определенного c месяца. Можно ли выполнять эту операцию на бизнес-уровне? На самом деле это можно считать связанным с бизнесом, или я должен перенести это в DAL и по-другому проектировать мою базу данных?

Второй подход: Должен ли я иметь подобный объект в DAL on Business и выполнять всю сортировку на слое ViewModel, то есть иметь бизнес-методы, возвращающие Total ammount для определенных c категорий и периодов, вызывая его в al oop и заполнение пользовательской модели представления категории.

Каковы плюсы / минусы каждого подхода?

1 Ответ

1 голос
/ 18 февраля 2020

По моему мнению , любой подход в порядке в зависимости от вашего варианта использования.

  1. Если вы вычисляете итоги в самом запросе SQL, лучшим способом будет поставить это в DAL.
  2. Если вы берете необработанные данные из базы данных и применяете некоторые бизнес-логи c, лучше использовать BLL.
  3. Если вы не применяете какие-либо бизнес-логи c и это просто логика представления c для суммирования чисел, и ваша инфраструктура пользовательского интерфейса лучше справляется с этим, уровень пользовательского интерфейса (возможно, ViewModel) тоже подойдет.

Я лично откажусь от пункта 3 выше. Я приму решение на основании того, вычисляю ли я итоги в SQL Запросе или нет. Исходя из этого, я выберу 1 или 2 сверху.

...