Проектирование Viewmodels и избегать if else операторов в контроллерах и написание хорошей бизнес-логики asp.net web api с использованием шаблонов проектирования

Question

У меня есть метод действия веб-API, который в качестве параметра (Post) принимает значение «Модель».

 public class RequestModel
 {
    public string PartType { get; set; }
    public int Quantity { get; set; }
    public decimal UnitCost{ get; set; }
    public bool? Owner { get; set; }
    public bool? DoSplit { get; set; }
 }

Параметры Владелец / Делить разделение будут выбраны пользователем в пользовательском интерфейсе и основаны на типе детали.Также на основе флага владельца есть некоторая другая бизнес-логика, которую необходимо выполнить в сочетании с DoSplit и Количество.Следовательно, у меня много перестановок и комбинаций.Если пойти грубо, логика пошла бы следующим образом:

int existingQty = GetInitialQuantity(model.SerialId); //returns esisting qty 
if(existingQty < model.Quantity && model.Owner)
{
  // logic here
}
else if (existingQty < model.Quantity && model.Owner == false)
{

}
else if (existingQty = model.Quantity) // no need to check for DoSplit
{
}
etc..... more if else in combincation with qty comaprison, Dosplit and owner  flag checks with null checks.

в зависимости от различных значений свойств в модели (в комбинации). Мне нужно выполнить разные действия.Как этого избежать и использовать правильные шаблоны проектирования C # здесь.Так как модель передается из javascript через вызов web api моему методу действия, как я могу использовать здесь ООП для модели запроса и избежать ветвления в методе контроллера?

Answer 1

Я думаю, что одна из главных причин того, что у вас так много, если / еще, заключается в том, что у вас нет бизнес-логики в самом объекте, но вы пытаетесь использовать бизнес-логику извне.Поскольку я не понимаю, какова ваша бизнес-логика, моя реализация может не сработать в вашем случае, но я хочу показать вам, как избавиться от if if в простом случае.Основная цель - не использовать свойства, а только использовать функции и позволить объекту самостоятельно обрабатывать свое состояние.(поиск Tell Dont Ask и State Pattern)

давайте посмотрим на этот класс

public class User
{
    string name { get; set; }
    bool isDisabled { get; set; }
}

, используя его, возможно, вот так

if (!user.isDisabled)
{
    user.name = nameFromApi
}

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

public interface IUser
    {
        string name { get; }
        IUser updateName(string newName);
        IUser disableUser();
    }


    public class DisabledUser : IUser
    {
        public DisabledUser(IUser activeUser)
        {
            this.name = activeUser.name;
        }

        public string name { get; }
        public IUser updateName(string newName)
        {
            return this;
        }

        public IUser disableUser()
        {
            return new DisabledUser(this);
        }
    }

    public class ActiveUser : IUser
    {
        public ActiveUser(IUser user)
        {
            this.name = user.name;
        }
        public string name { get; private set; }

        public IUser updateName(string newName)
        {
            this.name = newName;
            return this;
        }

        public IUser disableUser()
        {
            return new DisabledUser(this);
        }
    }

Таким образом, если if пропало, и вы действительно получили что-то другое: вы можете легко расширить реализацию с другими состояниями, такими как banned, и вам не нужно менять старую реализацию.Да, это больше кода, но проще в обслуживании.В вашем случае, я думаю, вы сможете избавиться от всех if / elses относительно логических флагов, если вы правильно инициализируете объекты.Это мощный шаблон, и вам не нужно ничего разыгрывать, чтобы иметь возможность использовать пользователя.Я не знаю ваш сценарий использования количества, поэтому я не могу сказать вам, как это можно решить, но, безусловно, есть способ сделать это.