所做的是系统中的一个模块A,为了程序的扩展性,使用了3层结构,如下图所示:
代码修改的一个范例
这样是比较容易扩展和修改的结构,数据的展现和数据的持久化相互不会影响,并把业务逻辑封装在一起。
模型代码为:
 1代码修改的一个范例 using System;
 2代码修改的一个范例 
 3代码修改的一个范例 namespace Example
 4}

由于开始数据库的设计不是很合理,把A模块的信息都集中存放在一个表中,用一个对象来表示,结果到现在变得不易与其他模块共用数据,所以就把这个表拆成几个小表,形成多个小对象,并关联起来。
由于我思维定势,在修改了数据持久层后又去修改业务逻辑层。把原本好的设计的优势浪费了 。
改动为(不好的修改):
  1代码修改的一个范例using System;
  2代码修改的一个范例 
  3代码修改的一个范例namespace Example
  4}

本来这样的改动是不用修改界面展现层和业务逻辑层的,只要在业务逻辑层和数据持久化层插入一个数据对象转换层就能很好的解决问题。
比较好的解决方法是:
代码修改的一个范例
模型代码为(好的修改):
  1代码修改的一个范例using System;
  2代码修改的一个范例 
  3代码修改的一个范例namespace Example
  4}

即是说,好的修改应该是内聚的。

相关文章:

  • 2021-12-05
  • 2022-03-08
  • 2022-02-18
  • 2022-02-01
  • 2021-11-25
  • 2022-01-27
  • 2021-10-30
  • 2022-12-23
猜你喜欢
  • 2022-12-23
  • 2021-07-17
  • 2022-02-04
  • 2021-06-24
  • 2021-10-15
  • 2022-12-23
相关资源
相似解决方案