Добавить простую бизнес-логику в хранилище в ASP> NET MVC 3 C # - PullRequest
1 голос
/ 07 апреля 2011

У меня есть вопрос, касающийся проблемы, которая уже много раз обсуждалась в stackoverflow (я извиняюсь за это), но никакого общего ответа не было дано из-за субъективности темы от одного случая к другому: можем ли мы добавить бизнеслогика для уровня хранилища в соответствии с шаблоном хранилища?У меня есть приложение MVC 3 с ViewModels (это означает, что я вообще не использую ViewData).Модель представляет собой LinqtoSQL EF, конечно, подключенный к базе данных.В настоящее время я обращаюсь к сущностям напрямую из контроллеров, которые содержат всю бизнес-логику, и оборачиваю данные, необходимые для представлений, в конкретные модели представления.Теперь я начинаю рефакторинг и понял, что лучший способ избежать дублирования кода, помимо оптимизации ViewModels, - это делегировать все запросы в хранилище, которое связывается с EF, и создавать специализированные методы, которые будут использоваться контроллером.Теперь, учитывая, что я хотел бы, чтобы хранилище возвращало реальные объекты, а не выражения, я думал о делегировании небольших кусочков бизнес-логики в хранилище, чтобы сделать мой код более понятным.Однако ради слабой связи хотелось бы узнать ваше мнение.В приведенном ниже коде (который в настоящее время находится в контроллере) все переменные, кроме lprojectionPercactualValue , взяты из базы данных.Поэтому я хотел переместить этот фрагмент кода в хранилище и вызвать метод с подписью:

public string getColor (int ItemId, float lprojectionPercactualValue);

Для метода требуется ItemId , чтобы получить значения, специфичные для этого элемента.Что вы думаете об этом дизайнерском решении?Лучше оставить код в контроллере, перейти к другому методу, все еще находящемуся в контроллере (создать метод или даже выделенный класс), или переместить его в репозиторий, как объяснено?

if (litem.Ascending == true)
{
    if (lprojectionPercactualValue < lminThreshold)
    {
        lcolor = "RED";
    }
    else if (lprojectionPercactualValue > lminThreshold && lprojectionPercactualValue < lmedThreshold)
    {                                   
        lcolor = "YELLOW";
    }
    else //(percValue >= item.Max_Threshold)
    {
        lcolor = "GREEN";
    }
}

else
{
    if (lprojectionPercactualValue > lminThreshold)
    {
        lcolor = "RED";
    }
    else if (lprojectionPercactualValue < lminThreshold && lprojectionPercactualValue > lmedThreshold)
    {
        lcolor = "YELLOW";
    }
    else //(percValue <= item.Max_Threshold)
    {
        lcolor = "GREEN";
    }
}

Ответы [ 3 ]

0 голосов
/ 07 апреля 2011

Оберните свою логику EF в слой DAL, который вы проксируете через класс Repository.Это необработанные данные, и, поскольку вам требуется дополнительная обработка, рекомендуется иметь уровень обслуживания, который использует их и применяет к ним ваши пользовательские бизнес-правила.Репозиторий здесь предназначен для предотвращения любого дублирования кода БД.

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

0 голосов
/ 08 апреля 2011

ИМХО, вам лучше добавить бизнес-уровень между контроллером и репозиторием и поместить приведенный выше код getColor на бизнес-уровень (или даже разбить его на несколько методов, если это необходимо), что если вам это нужно в других контроллерах, Что если это больше не простой if / else, что если вам нужно завтра получить значения порогов от веб-службы, хотите ли вы внести все эти изменения в ваш контроллер или код репозитория?

0 голосов
/ 07 апреля 2011

Не рекомендуется.

Как теперь репозиторий о lminThreshold? Что, если само это значение должно быть получено из таблицы поиска или файла конфигурации?

Переместите его на бизнес-уровень - и, если у вас его нет, на контроллер.

...