design-patterns - 为什么我的关注点分离数据库/业务对象/Web 服务，让我写更多的代码？

Question

我已经阅读了很多关于软件设计的书籍，而且我越来越想知道我所学到的关于业务对象和序列化之间的关注点分离的知识是否让我更有效率。

我受到领域驱动设计的影响，所以当我设计我的业务类时，我不会考虑持久性。与我的数据库/Web 服务技术/缓存技术耦合的唯一对象被封装在具有良好域接口(interface)的存储库后面。

为了说明，对于传统的应用程序数据库<->Web 服务<->RIA，我设计了我的业务类Account 和Employee。
然后，如果我想从数据源获取帐户，我会创建一个 IAccountRepository，并实现查询方法或将帐户添加到我的数据源。

要为我的应用程序添加缓存功能，只需创建一个代理类，它实现 IAccountRepository 并包装真实存储库，然后将其注入(inject)我的 IOC 容器中。

为了实现数据库存储库，我使用 ORM 从我的数据库模式创建类，然后我使用创建翻译器将数据库类转换为业务类/从业务类转换，这样我的业务类与我的数据库模式分离。

我还为我的 Web 服务创建了专用的数据契约类，然后 Web 服务使用转换器将业务对象的聚合转换为从 Web 服务角度来看的数据表示。

当我创建我的 RIA 应用程序时，我再次设计了它自己的域模型，但这次存储库实现使用 Web 服务而不是数据库(以及翻译器)。

对于 WPF 开发人员，我创建了我的 ViewModel 和我的 View。

我以前是这样编程的。

但是，当我的老板来说:你能在这个表格中添加一个字段来......等等等等，我必须:

更新我的数据库

更新我的数据库翻译器

更新我的业务对象

更新我的网络服务翻译器(服务器)

更新我的网络服务翻译器(客户端)

更新我的业务对象(客户端)

更新我的观点

对于 WPF 专家，请更新我的 ViewModel

我越来越想将我的业务对象与数据库访问技术和 Web 服务技术或序列化技术结合起来。

这样我就不再需要维护我的翻译器了。
例如，为什么不在业务对象上使用这些技术的属性/注释？是的，它带来了一些限制，是的，我需要在我的字段上获取/设置，即使我希望我的属性是只读的，是的，我的业务模块将具有外部依赖项。
但我认为这将导致更少的代码和更易于维护的系统。

我的存储库的实现将是微不足道的，并且不会依赖翻译。

虽然我看到了这样编码的好处，但我总是对这样的编码感到内疚。我对在我的业务对象上添加 5 个属性/注释以及我的数据访问技术/Web 服务技术/序列化技术感到非常内疚，我觉得这是不对的。

为什么我的关注点分离数据库/业务对象/Web 服务，让我写更多的代码？

你有其他选择吗？

Answer 1

你的个人生产力不是重点。

关注点分离的重点是增加值(value) 通过使其可用、可维护和可适应的方式来提高您生产的软件的值(value)。

如果这让您编写更多代码，我很抱歉，但您的时间通常只是使用、维护和调整您正在编写的内容的生命周期成本的一小部分。

关注点分离本质上是为了降低终生总拥有成本。它与您的个人生产力无关。

如果你的老板要求你进行普遍的改变……嗯……这是普遍的。我很抱歉它无处不在。

编辑 1

值(value) 您的软件的值(value)是人们创造的值(value)使用 它。

“是代码的纯度/美感吗？对我来说，值(value)在于简单性和可读性。”两者都不是。这是将代码应用于实际问题所创造的值(value)。

如果代码难以维护、调整或使用，那么它就会贬值。如果代码易于维护、调整或使用，那么从代码中获得全部值(value)的障碍就会更少。

与使用它的值(value)相比，您开发代码的时间是非常微小的成本。此外，与维护或适应相比，您的开发时间成本更低。

编辑 2

普遍的变化是构建软件不可避免的结果。没有什么——没有实践——可以阻止你的老板做出破坏你的架构的改变。

如果您有一层，几乎任何更改都会破坏该层。

如果你有 3 层、7 层或 n+1 层，你的老板总是有可能要求改变不止一层。

这个想法是大多数更改是孤立的。没有什么可以保证所有更改都是隔离的。