13 个解决方案
#1
到底有什么问题？没看明白。
不要用编程术语，用完全不懂编程的人说一下问题。要是你能把出现的问题给完全不懂变成的人说明白了，这才算是值得学习编程。反之如果因为学了编程而无法说明白用户需求了（满脑子只有技术名词儿了），那么编程时肯定也越来越乱。
不要用编程术语，用完全不懂编程的人说一下问题。要是你能把出现的问题给完全不懂变成的人说明白了，这才算是值得学习编程。反之如果因为学了编程而无法说明白用户需求了（满脑子只有技术名词儿了），那么编程时肯定也越来越乱。
#2
如果你想说“业务逻辑随便修改，数据库胡乱设置，而客户端代码与之不一致”，那么这想要什么解决方案？相关的胡乱修改数据库值人员要为自己的行为负责，应该面临被辞退啊？！还能怎样？
#3
客户端包含一个脚本引擎，服务器返回脚本，定义逻辑，客户端执行脚本。典型的，b/s系统+js可以实现。
#4
您说的有道理，理论上应该是一经定义，尽可能不变动。正是由于这种约定，一般情况客户端都采用硬编码方式。我是假设有可能发生变化了之后，客户端不改动任何代码的情况下，程序可以健壮的运行。
也就是说我想求得一种客户端不采用硬编码的方式的解决方案。若您有相关的经验或者思路，请不吝赐教。
#5
嗯呢， 谢谢，这个思路可行，您的方案是类似于动态编译执行的思路吧？例如服务器定义一套语法规则之类的，(i=3 ok i = 4 no)，客户端加载这个规则，解析，并执行是吗？
客户端可能是APP,浏览器,应用程序。
#6
客户端动态加载服务端的配置规则不就好了
#7
网页的话,相关脚本写js文件里,改js就好,怎么改都是改,反正也不影响用户那边的体验
app和应用程序的话可以做个升级功能啊,如果你给每个接口定义一个规则,后台更新下规则,不就相当于自动升级功能?
app和应用程序的话可以做个升级功能啊,如果你给每个接口定义一个规则,后台更新下规则,不就相当于自动升级功能?
#8
楼主可以换个设计思路：
可不可登录，和用户状态代码是两种属性，
具体到楼主的例子，意思就是这样的：
用户状态定义：
UserStatusId：唯一标识，比如说GUID，序列，自增等
UserStatusName：比如：启用，禁用，
UserStatusCode：比如：1，2，3，4，
AllowLogon：bool值，只能是：1或者0
可不可登录，和用户状态代码是两种属性，
具体到楼主的例子，意思就是这样的：
用户状态定义：
UserStatusId：唯一标识，比如说GUID，序列，自增等
UserStatusName：比如：启用，禁用，
UserStatusCode：比如：1，2，3，4，
AllowLogon：bool值，只能是：1或者0
#9
对客户端来说，这就是需求变更，而且是那种很少发生的，有严重后果的改变。
所以在开发客户端时，根本没必要考虑将来会有这种变化。
否则肯定是过度设计，一天的活变成十天。
所以在开发客户端时，根本没必要考虑将来会有这种变化。
否则肯定是过度设计，一天的活变成十天。
#10
对于允许登陆、不允许登陆，就只有两种情况，那么服务端就应该只返回bool值来显示告诉是否允许登陆，而不是返回状态码让客户端判断，这样客户端不就包含业务逻辑了
#11
其实就返回两个状态:TRUE Or FALSE，像1234什么的都不就是这两个值么
#12
连用户状态的定义都会变更的系统谁还敢用？
#13
此场景正常程序完全不会遇到，因为程序员们根本就不会这么做系统
1.数据里保存什么和逻辑判定没有关联
2.逻辑判定是业务逻辑的事情，不是客户端展示的事情。我凭啥要把自己的业务规定，展示给客户端？？
3.正常逻辑是， {执行状态， 错误码，附属对象}，而不是丢只一个错误码
1.数据里保存什么和逻辑判定没有关联
2.逻辑判定是业务逻辑的事情，不是客户端展示的事情。我凭啥要把自己的业务规定，展示给客户端？？
3.正常逻辑是， {执行状态， 错误码，附属对象}，而不是丢只一个错误码
#1
到底有什么问题？没看明白。
不要用编程术语，用完全不懂编程的人说一下问题。要是你能把出现的问题给完全不懂变成的人说明白了，这才算是值得学习编程。反之如果因为学了编程而无法说明白用户需求了（满脑子只有技术名词儿了），那么编程时肯定也越来越乱。
不要用编程术语，用完全不懂编程的人说一下问题。要是你能把出现的问题给完全不懂变成的人说明白了，这才算是值得学习编程。反之如果因为学了编程而无法说明白用户需求了（满脑子只有技术名词儿了），那么编程时肯定也越来越乱。
#2
如果你想说“业务逻辑随便修改，数据库胡乱设置，而客户端代码与之不一致”，那么这想要什么解决方案？相关的胡乱修改数据库值人员要为自己的行为负责，应该面临被辞退啊？！还能怎样？
#3
客户端包含一个脚本引擎，服务器返回脚本，定义逻辑，客户端执行脚本。典型的，b/s系统+js可以实现。
#4
您说的有道理，理论上应该是一经定义，尽可能不变动。正是由于这种约定，一般情况客户端都采用硬编码方式。我是假设有可能发生变化了之后，客户端不改动任何代码的情况下，程序可以健壮的运行。
也就是说我想求得一种客户端不采用硬编码的方式的解决方案。若您有相关的经验或者思路，请不吝赐教。
#5
嗯呢， 谢谢，这个思路可行，您的方案是类似于动态编译执行的思路吧？例如服务器定义一套语法规则之类的，(i=3 ok i = 4 no)，客户端加载这个规则，解析，并执行是吗？
客户端可能是APP,浏览器,应用程序。
#6
客户端动态加载服务端的配置规则不就好了
#7
网页的话,相关脚本写js文件里,改js就好,怎么改都是改,反正也不影响用户那边的体验
app和应用程序的话可以做个升级功能啊,如果你给每个接口定义一个规则,后台更新下规则,不就相当于自动升级功能?
app和应用程序的话可以做个升级功能啊,如果你给每个接口定义一个规则,后台更新下规则,不就相当于自动升级功能?
#8
楼主可以换个设计思路：
可不可登录，和用户状态代码是两种属性，
具体到楼主的例子，意思就是这样的：
用户状态定义：
UserStatusId：唯一标识，比如说GUID，序列，自增等
UserStatusName：比如：启用，禁用，
UserStatusCode：比如：1，2，3，4，
AllowLogon：bool值，只能是：1或者0
可不可登录，和用户状态代码是两种属性，
具体到楼主的例子，意思就是这样的：
用户状态定义：
UserStatusId：唯一标识，比如说GUID，序列，自增等
UserStatusName：比如：启用，禁用，
UserStatusCode：比如：1，2，3，4，
AllowLogon：bool值，只能是：1或者0
#9
对客户端来说，这就是需求变更，而且是那种很少发生的，有严重后果的改变。
所以在开发客户端时，根本没必要考虑将来会有这种变化。
否则肯定是过度设计，一天的活变成十天。
所以在开发客户端时，根本没必要考虑将来会有这种变化。
否则肯定是过度设计，一天的活变成十天。
#10
对于允许登陆、不允许登陆，就只有两种情况，那么服务端就应该只返回bool值来显示告诉是否允许登陆，而不是返回状态码让客户端判断，这样客户端不就包含业务逻辑了
#11
其实就返回两个状态:TRUE Or FALSE，像1234什么的都不就是这两个值么
#12
连用户状态的定义都会变更的系统谁还敢用？
#13
此场景正常程序完全不会遇到，因为程序员们根本就不会这么做系统
1.数据里保存什么和逻辑判定没有关联
2.逻辑判定是业务逻辑的事情，不是客户端展示的事情。我凭啥要把自己的业务规定，展示给客户端？？
3.正常逻辑是， {执行状态， 错误码，附属对象}，而不是丢只一个错误码
1.数据里保存什么和逻辑判定没有关联
2.逻辑判定是业务逻辑的事情，不是客户端展示的事情。我凭啥要把自己的业务规定，展示给客户端？？
3.正常逻辑是， {执行状态， 错误码，附属对象}，而不是丢只一个错误码