Nic*_*ier 7 architecture design-patterns
我已经阅读了很多关于软件设计的书籍,而且越来越多我想知道我在业务对象和序列化之间分离关注点所学到的东西是否能让我更有成效.
我受域驱动设计的影响,所以当我设计我的业务类时,我不会考虑持久性.与我的数据库/ Web服务技术/缓存技术相关联的唯一对象被封装在具有良好域接口的存储库后面.
为了说明,对于传统的应用程序数据库< - > Web服务< - > RIA,我设计了我的业务类Account和Employee.然后,如果我想从数据源获取帐户,我创建一个IAccountRepository,并实现查询或将帐户添加到我的数据源的方法.
要向我的应用程序添加缓存功能,只需创建一个代理类来实现IAccountRepository并包装真实存储库,然后将其注入我的IOC容器中.
为了实现数据库存储库,我使用ORM从我的数据库模式创建类,然后我使用create a translator将数据库类转换为业务类,这样我的业务类就与我的数据库模式分离.
我还为我的Web服务创建专用数据协定类,然后Web服务使用转换器将业务对象的聚合从Web服务角度转换为其数据表示.
当我创建我的RIA应用程序时,我再次设计自己的域模型,但这次存储库实现使用Web服务而不是数据库(以及翻译器).
对于WPF开发人员,我创建了我的ViewModel和我的View.
我曾经这样编程.
但是,当我的老板来时,说:你可以在这个表格中添加一个字段...... 等等等等等等我必须:
我越来越想将业务对象与数据库访问技术和Web服务技术或序列化技术结合起来.
这样我就不再需要维护翻译了.例如,为什么不在业务对象上使用这些技术的属性/注释？是的它带来了一些禁忌,是的,我需要在我的字段上获取/设置,即使我希望我的属性是只读的,是的,我的业务模块将具有外部依赖性.但我认为这将导致更少的代码和更可维护的系统.
我的存储库的实现将是微不足道的,不会依赖于翻译.
虽然我看到这样编码的优点,但我总是对这样的代码感到内疚.在我的业务对象上添加5个属性/注释以及我的数据访问技术/ Web服务技术/序列化技术,我感到非常内疚,我觉得这是不对的.
为什么我分离关注数据库/业务对象/ Web服务,让我编写更多代码？
你有其他选择吗？
你的个人生产力不是重点.
关注点的分离点是通过使其可用,可维护和适应性来增加您生产的软件的价值.
如果这会让你写更多代码,我很抱歉,但你的时间通常只是使用,维护和调整你所写内容的终生成本的一小部分.
关注点的分离主要是为了保持终身的总体拥有成本.它与您的个人生产力无关.
如果你的老板要求你进行普遍的改变......那么......它是无处不在的.对不起它很普遍.
编辑1
该值你的软件是由人产生的数据使用它.
"这是代码的纯洁/美丽吗？对我而言,价值在于简单性和可读性." 它既不是.这是将代码应用于现实问题所创造的价值.
如果代码难以维护,调整或使用,则会使代码贬值.如果代码易于维护,调整或使用,那么从代码中获取全部价值的障碍就会减少.
与使用它的价值相比,开发代码的时间很短,成本很小.此外,您的开发时间比维护或调整成本更低.
编辑2
普遍的变化是构建软件的不可避免的后果.没有 - 没有练习 - 可以阻止你的老板做出破坏你的架构的改变.
如果您有一个图层,那么几乎任何更改都会破坏该图层.
如果您有3层,7层或n + 1层,那么您的老板总是可以要求进行多个层的更改.
这个想法是MOST的变化是孤立的.没有什么可以确保所有变化都是孤立的.
设计应用程序时，抽象级别应该提供价值。他们不应该仅仅因为这是“最佳实践”而在那里。一些应用程序具有丰富的域模型并受益于抽象层。但是，非常以数据为中心而没有太多逻辑的应用程序可能不需要那么多层。
我见过一些应用程序定义了与每个对象相对应的多个层，其名称尽职地与层 EmployeeDL、EmployeeBL、EmployeeUL 相匹配。这些对象都没有添加任何值，只是在层之间从用户界面到数据库传递值。这是毫无意义的。
我发现在使用具有更丰富域模型的应用程序时，更改可能会影响多个层，但很少像将值从 UI 通过多个层传递到数据库那样简单。中间有业务逻辑，如果没有抽象级别，实现起来会困难得多。
归根结底，选择一个在复杂性和可维护性方面满足应用程序需求的架构是最重要的。