在控制器层上写决策语句
我们正在开发一个基于MVC架构的REST应用程序。
服务层正在返回Optional<T>，其中T可以是任何类。
因此，在控制器层上有一个条件语句，该语句测试结果是否为Optional.empty，然后使用数据[]返回自定义响应；否则，在自定义响应HTTP响应中返回实际数据。
return ABCService
.getById("")
.map("custom response with actual data ")
.orElse(Collections.empty in Custom response)
;在Controller层中编写这段代码是一种不好的做法吗？
我们返回Optional<T>是因为我们不想发送null。如果我们不对Controller层使用这个条件，我们也必须从服务层删除返回的Optional，我不认为这是一个好的实践。
有人能解释一下为什么上面的代码不是很好的实践吗？会有什么后果？
回答 1
Software Engineering用户
发布于 2017-09-17 17:21:37
这取决于你是如何实现MVC的。MVC没有规定M、V和C之间的通信方式。如果您正在执行这，您的代码是有意义的：
但如果你做的是这，那就不行了：
您应该做的主要取决于您对命令查询责任分离的感受。
告诉我你在使用MVC并不能告诉我多少。这是一种旧的设计模式，已经以许多不同的方式重新发明了。在这一点上，唯一一致的一点是将三个责任领域分开的想法。
10亿美元的错误是允许null进入打字系统。除非您使用一种修复您所使用的可空类型的语言。
小心不返回null是另一回事。您避免返回null，因为null的含义从一个上下文到另一个上下文并不清楚，并且它所导致的行为通常是无意的。返回一个空对象可以让您控制行为，并使含义变得清晰。这只需将字符串设置为"“而不是null即可。
使用Optional可以获得类似的效果，而无需定义null对象类，因为Optional实际上是一个容器。与其让你接受一个当你点缀掉它时就会爆炸的null，Optional的作用就像一个什么都不包含的ArrayList。
Optional并没有阻止null存在。它只是抽象地处理掉它。它有效地将您的if (foo != null)检查填充到Optional中，这样您就不必查看它们。它也只有在您继续使用Optional的情况下才能工作。一旦你摆脱了Optional，直接接触到里面的东西，你就回到了你开始的地方，和null打交道。
忠实地在您的返回中避免null可能听起来很有吸引力，但是要明白，仅仅因为有东西说返回，Optional并不意味着他们仍然不能继续欺骗您，有时还会返回一个裸露的null。打字系统不能让你做出这样的承诺。这就是数十亿美元的错误。
https://softwareengineering.stackexchange.com/questions/357565
复制相似问题
腾讯云开发者
