设计 – 为什么我的关注点分离数据库/业务对象/ Web服务,让我编

我受域驱动设计的影响,所以当我设计我的业务类时,我不会考虑持久性.与我的数据库/ Web服务技术/缓存技术相关联的唯一对象被封装在具有良好域接口的存储库后面.

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

要向我的应用程序添加缓存功能,只需创建一个代理类来实现IAccountRepository并包装真实存储库,然后将其注入我的IOC容器中.

为了实现数据库存储库,我使用ORM从我的数据库模式创建类,然后我使用创建转换器将数据库类转换为业务类或从业务类转换数据库类,这样我的业务类就与我的数据库模式分离.

我还为我的Web服务创建专用数据协定类,然后Web服务使用转换器将业务对象的聚合从Web服务角度转换为其数据表示.

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

对于WPF开发人员,我创建了我的ViewModel和我的View.

我曾经像这样编程.

但是,当我的老板来时,说：你可以在这个表格中添加一个字段……等等等等等等我必须：

>更新我的数据库
>更新我的数据库翻译器
>更新我的业务对象
>更新我的Web服务转换器(服务器)
>更新我的网络服务翻译(客户端)
>更新我的业务对象(客户端)
>更新我的观点
>对于WPF专家,请更新我的ViewModel

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

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

我的存储库的实现将是微不足道的,不会依赖于翻译.

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

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

你有其他选择吗？

解决方法

关注点的分离点是通过使其可用,可维护和适应性来提高您生产的软件的价值.

如果这会让你写更多代码,我很抱歉,但是你的时间通常只是使用,维护和调整你所写内容的终生成本的一小部分.

关注点的分离主要是为了保持终身的总体拥有成本.它与您的个人生产力无关.

如果你的老板要求你进行普遍的改变……那么……它是无处不在的.对不起它很普遍.

编辑1

软件的价值是使用它的人产生的价值.

“这是代码的纯洁/美丽吗？对我来说,价值在于简单性和可读性.”它既不是.这是将代码应用于现实问题所创造的价值.

如果代码难以维护,调整或使用,则会使代码贬值.如果代码易于维护,那么从代码中获取全部价值的障碍就会减少.

与使用它的价值相比,您开发代码的时间微不足道.此外,您的开发时间比维护或调整成本更低.

编辑2

普遍的变化是构建软件的不可避免的后果.没有 – 没有练习 – 可以阻止你的老板做出破坏你的架构的改变.

如果您有一个图层,那么几乎任何更改都会破坏该图层.

如果您有3层,7层或n层,那么您的老板总是可以要求进行多层的更改.

这个想法是MOST的变化是孤立的.没有什么可以确保所有变化都是孤立的.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!