【问题标题】:Server-side permanent state management服务器端永久状态管理
【发布时间】:2017-04-20 11:03:32
【问题描述】:

我正在寻找一种简单的方法来处理我的服务器端代码中的永久状态。

有几点我需要考虑:

  • 状态存储在数据库中
  • 不同的对象有不同的状态,处理方式也不同

这意味着我例如。有两种不同类型的对象Models 和Parameters,这些对象中的每一个都有一个存储在我的数据库中的状态属性。

当前端调用我的公共函数之一时,我需要验证给定对象的当前状态,以查看操作是否有效。

在我的后端处理这个问题的最佳方法是什么?

最初的尝试

public class StateManager
{
    bool HandleState<T>(T state);
}

有点像这样称呼

myStateManager.HandleState<ModelState>(GetStateFromDatabase(myModelId));

并像这样实现

bool HandleState<T>(T state)
{
   switch(T)
   {
       case ModelState:
           switch(state) 
           {
               case ModelState.Ready:
                  return true;
           }  
      case ParameterState:
          switch(state)
          {
              case ParameterState.Ready:
                  return true;
          }    
   }
}

上面的解决方案不起作用,因为我无法对 T 进行大小写,因为它是 Enum 类型,而不是简单类型。

我正在寻找易于扩展的东西,既具有新的状态类型,也具有新的状态值。

【问题讨论】:

  • 所以回顾一下:“我如何在数据库中存储东西?”这是一个非常广泛的问题。到目前为止,您尝试过什么?
  • 我阅读了我最初的想法,它显示了我想要实现的目标,但在显示的格式中是不可能的。回顾一下:我不是在寻找存储状态的方法——我已经知道了。我正在寻找一种方法来制作验证方法,当后端接收到调用时可以调用该方法以查看它是否有效执行(基于状态)

标签: c# asp.net switch-statement state backend


【解决方案1】:

可能的解决方案:
一个工厂,它产生一个实现通用状态处理程序接口的对象,该接口接受 T ... 和处理枚举的 x 实现 ...

我知道的大多数 ioc 容器的标准东西...

通过ioc注册状态处理接口的实现

致电您的工厂以获得正确的实施方式

即使没有 ioc 容器也易于实现(如果您需要示例,请告诉我,以防您的 googlefoo 不足)

示例:

namespace playground
{
    public class Program
    {
        public static void Main()
        {
            var testcase1 = DummyStateType1.State1;
            var testcase2 = DummyStateType2.OtherState1;

            var handler1 = StateHandlerFactory<DummyStateType1>.Create();
            var handler2 = StateHandlerFactory<DummyStateType2>.Create();

            var result1 = handler1.handle(testcase1);
            var result2 = handler2.handle(testcase2);

            var alsoResult1 = tadaaaa(testcase1);
            var alsoResult2 = tadaaaa(testcase2);
        }
        static bool tadaaaa<T>(T state)
        {
            return StateHandlerFactory<T>.Create().handle(state);
        }
    }
    public interface IStateHandler<T>
    {
        bool handle(T state);
    }
    public enum DummyStateType1
    {
        State1,
        State2
    }
    public enum DummyStateType2
    {
        OtherState1,
        OtherState2
    }
    public static class StateHandlerFactory<T>
    {
        public static IStateHandler<T> Create()
        {
            //this could be replaced by IoC ... or a reflection based lookup ... you name it...
            var type = typeof(T);
            if (type == typeof(DummyStateType1))
                return (IStateHandler<T>)new DummyStateType1StateHandler();
            if (type == typeof(DummyStateType2))
                return (IStateHandler<T>)new DummyStateType2StateHandler();
            throw new NotImplementedException();
        }
    }
    public class DummyStateType1StateHandler : IStateHandler<DummyStateType1>
    {
        public bool handle(DummyStateType1 state)
        {
            switch (state)
            {
                case DummyStateType1.State1:
                    return false;
                case DummyStateType1.State2:
                    return true;
                default:
                    throw new NotImplementedException();
            }
        }
    }
    public class DummyStateType2StateHandler : IStateHandler<DummyStateType2>
    {
        public bool handle(DummyStateType2 state)
        {
            switch (state)
            {
                case DummyStateType2.OtherState1:
                    return true;
                case DummyStateType2.OtherState2:
                    return false;
                default:
                    throw new NotImplementedException();
            }
        }
    }
}

【讨论】:

  • 如果你能画出你的解决方案,我们将不胜感激:)
  • @M.Larsen ... 给你
  • 但请记住,它没有编译时安全性...编译器不知道您是否为 T 使用了没有实际实现的东西...
  • 谢谢。我喜欢你的解决方案,因为它的可扩展性,但我最初是在寻找一个解决方案,其中一个类的实例可以同时处理 DummyStateType1 和 DummyStateType2 而无需创建单独的 StateManager 实例。我确实也在寻找一种轻量级的方式来检查状态,这与处理“太多”的想法相矛盾,所以我选择了你的解决方案并扩展它是必要的。
  • 这个想法是“关注点分离”......一个类与一个状态枚举有关......如果你想要它“更小”,比如每个枚举没有额外的类,你可以和代表一起去而不是 IStateHandler,使用一些 Func 并让一个类提供所有 Func 实例......但是一旦它变得更大,我会称之为一团糟......
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-03-16
  • 2012-03-03
  • 1970-01-01
  • 1970-01-01
  • 2019-03-28
  • 2013-01-30
  • 1970-01-01
相关资源
最近更新 更多