那么今天来一期真实的业务场景。（不能原样照搬业务，套个业务逻辑高度相似百ci斩的壳）
- 选择zh or en 语言
- 根据语言选择选择对应题型，（英语没有字的概念无字）
- 根据库中题型拿出的数据做业务逻辑处理。
- 然后持久化处理后的数据。（这个表无需关心）逻辑上认为有这么割表即可
拿起你的稿纸，自己构思怎么处理这个简单的业务。
！！！病友请遵守游戏规则。禁止在回复中写出你的逻辑。避免出现我在套路你们的解决方案问题。明晚，我将写出我的处理办法。
补充：数据库表（处理后保存的表无需关心）
35 个赞
mark
1 个赞
突然见到百词斩，好神奇
1 个赞
mark
1 个赞
mark
1 个赞
没看懂啊
1 个赞
想了想感觉纯sql就能实现了
1 个赞
学习一下
业务逻辑：未构思好谨慎查看。
让我猜猜看，是不是很多人觉得，弄4个service做个判断然后执行对应sql就完事了。 
技术栈：
1.RestFul规范
2.Validation参数校验
3.策略+工厂模式
4.ffmpeg转换工具
5.springboot
解决方案：
1.第一个需要判断入口。在我看来无论是中文还是英语它是固定通用的。即便是题型也大差不差。
那么使用RestFul规范能不能解决部分判断问题
/{language}/{queryType}/questions
那么好，已经无需关心语言入口了。
2.虽然前端可以限制正常用户的输入。但是要是恶意调用接口呢。
所以我使用了Validation做参数校验
3.那么再说题型判断与执行前，我在思考我需要对查出来的数据做处理。
那么无论我是用switch还是用if都是要判断题型的。如果某一天加了诗，词，歌赋呢，我也要堆砌么？
那么有没有更优雅的方法呢。既然是要做选择，那必定先联想到策略 
那么好，我定义了一个题型查询策略接口。做了对应题型的策略实现。然后定义一个context上下文配置类调用具体实体。
emm…优雅是优雅，还是得判断题型。执行对应实体。只不过判断转移到了上下文配置类中。还是不够优雅。闹心不 
有没有在优雅的解决方案么。那必须得有啊。既然要执行实体。那必须得创建对象。一想到创建对象那必须得来个工厂啊。
像我这种摆烂货肯定懒得写。好麻烦。嗯~ ？IOC，DI，RestFul，判断题型入口，工厂。那必须得捡现成的啊。
我将策略实体注册成组件并命名beanName。通过RestFul去对应beanName。
在策略上下文中注入BeanFactory。调用getBean(beanName,策略接口)。将现成的工厂组合到策略上下文中。beanName还是要校验的。猜猜看我拿到了什么。那么根据language调用具体实现还成问题么？嘿嘿嘿…
再看一眼/{language}/{queryType}/questions （queryType=beanName） RestFul规范,通过url路径拿语言。beanName。当然还有一个body中的语音参数。那么在执行数据处理时。我只需要通过配置好的ffmpeg转换语音。然后根据beanName调用策略上下文中工厂的getBean。是不是拿到指定的查询策略。调用指定策略根据language是不是拿到了，对应语言对应题型。
（此处是处理逻辑）语音，指定策略数据都拿到了。将对应参数根据接口规范交给AI链路接口。我是不是拿到了处理好的数据。以后即便加了诗词歌赋，哪怕加坨米田共。我只需要在策略中加一个实现即可。
3 个赞
（依然是偷袭套路，实际是明天出差实地部署。在熬夜赶文档）下个业务待定。（最近的业务是不能拿出来的）以前的业务不太好抉择，不太好套壳。（规避风险）那么你们有什么方案么？目前只针对业务来说。不要提redis这些。那是性能优化方案了。另外病友们，你们的方案最好注明业务逻辑然后隐藏起来。避免扰乱后来者思绪。
mark mark
插眼
为啥感觉你写的这么绕来绕去
1 个赞
看了一下思路描述，感觉自己想的话更多就是很直接， 没有什么设计模式，都是直来直去，也不会想着会拓展，也没想到使用接口来区分入口，就很直接的想着一堆数据进来通过 ascii 来区分中英文，接着直接操作然后就没然后了
看到springboot就有点害怕了，往下看果然是这些，策略，工厂，IOC，DI 
mark
mark
看来大伙还是喜欢用成品和看吹牛b，业务这是真没什么人看 
觉得绕，回去重修对象设计规则，在回来看为什么这么写就明白了。还不明白那就没办法了，多堆山堆多了就懂了
过度设计，你得说出个123吧。直接开火，你是不是，不太礼貌呢。看不上你可以左转出院带有攻击性就没必要了吧