面向对象对三层架构的影响？

Posted 2023-05-16

三层架构逻辑关系，55555555 晕的很？？
是不是面向对象，封装的理解不够好？
如何更好的理解三层架构？

原来所说的三层即：客户端（浏览器）-Web服务器-数据库服务器。
你说的所谓三层，是ASP.NET开发中，将数据访问放到一个中间层里面。最明显的就是使用ObjectDataSource。
首先，不要拘泥于所谓三层架构，如果不需要复杂的、数据源经常变动的数据处理，使用少一点的层次也无所谓。
其次，要理解三层或多层架构的应用场合。有时候我们的数据源可能来自不同的数据库服务器，甚至是数据表和其它对象的合并，而数据更新可能需要自定义的避免冲突的规则，或者我们已经预见到数据源可能经常变动，这时，用单独的数据处理层，会更灵活。
最后，对于ASP.NET，在MSDN查一下ObjectDataSource的范例，会了解到基本的三层应用方法，并加深三层应用的理解。
参考资料：http://www.alixixi.com/Down/softdown.asp?softid=22351;http://www.51aspx.com/CV/AspNet_sancengjiegou/ 参考技术A 不是啊，这是只个逻辑

面向对象——三层架构（表现层业务层持久层）

三层架构：即表现层、业务层、持久层。

① 持久层：采用DAO模式，建立实体类和数据库表映射（ORM映射）。也就是哪个类对应哪个表，哪个属性对应哪个列。持久层

               的目的就是，完成对象数据和关系数据的转换。

② 业务层：采用事务脚本模式。将一个业务中所有的操作封装成一个方法，同时保证方法中所有的数据库更新操作，即保证同时成

               功或同时失败。避免部分成功部分失败引起的数据混乱操作。

③ 表现层：采用MVC模式。

               M称为模型，也就是实体类。用于数据的封装和数据的传输。

               V为视图，也就是GUI组件，用于数据的展示。

               C为控制，也就是事件，用于流程的控制

 

设计原则：

           业务层接口的设计原则：一个实体类一个接口，一次提交一个业务方法。业务方法的参数来自表现层。

           持久层接口的设计原则：一个实体类一个接口，一次数据库操作一个持久方法。