三层架构与MVC

        这几天整理MVC与三层架构，有点晕晕的感觉，除了理论上的东西，其他的一点也没有了，只是模模糊糊的感觉到他的好处。

        具体到它的应用总感到无从下手，至少得在做工程中用到，但是这个架构也太大了，写文档，画Rose图（体现出三层架构），写代码，这三项都是我不太懂，至少是不熟悉，总感到迷迷糊糊。

       在网上找了个小例子，看看看，了解了了解，纵三有点眉目了。

       所谓的分层如果没有和代码结合起来只能是空谈，当和代码结合了才能理解了，只是具体到其中的细节就不是很了解了，至少还得琢磨一段时间。

       所谓的MVC即模型（model）视图（view）控制器（controller），其实就是将面向过程的一体分成了三个不同的部分（基于面向对象的思想），这样在面向对象的基础上完成了对一体的分解，其实说白了MVC就是通过调用类库里的类（类的实例化）来完成对三层中的不同职能的类的使用，这样就是简单的分层，即分层的表面，但是贯穿在层次之间的东西就是数据，即数据的流动，这是连接三层的一条线，即视图层（与用户交互的界面，就是所谓的窗体）将数据传给实体层（数据的中转站），而此时业务逻辑层将数据继续传输给数据层，在数据层中通过对传输过来的数据进行相应的数据操作（数据库的功能 增、删、改、查）达到我们需要对数据库进行的操作；这是数据下传的方向；相反的过程就是数据的上传（回传），即在业务逻辑层通过调用数据层的类将结果（数据）回调过来，进行业务逻辑操作，同时数据继续往回传，在视图层通过调用业务逻辑层的类将结果（数据）反射回来（我想在这个过程中，也需要实体层的参与，在数据曾完成数据的操作之后可以讲返回的结果存储在实体层中，这样视图层就可以直接调用返回的数据，而不必通过业务逻辑层的，业务逻辑层只是进行业务上的处理判断等）。

       关于为什么要使用分层，这点主要是为了降低耦合性，在MVC架构中，他的三个部分是相互独立的，改变其中一个不会影响到其他两个（这都是理论，理解起来有点费解），视图层和业务层的分离，这样在编译视图层的代码时，不用重新编译模型和控制器代码，这样在设计的时候就要充分考虑好各层之间需要怎样的数据操作结果，即我们各层的类要返回什么样的结果。这样就涉及到了画图，画图的时候就得考虑好数据的流动产生的结果。在一点就是高重用性可适用性，即不同的界面可以调用相同的构件（业务逻辑层），即界面层如果需要一些特定的数据就可以将通过调用一定的业务层的构件来完成相应的数据回传。之后就是快速的部署，适用MVC使得开发时间得到相当大的缩减，使程序员集中精力于业务逻辑，界面程序员集中精力于表现形式上。即分层来完成各自的任务，但是他们之间的数据阐述关系就得有一个统一的规定，总不至于各层干各层的，到头来发现驴唇不对马嘴，数据之间的传输乱七八座，的不多有效的管理，那还不如一个人写程序呢，这样图的重要性就体现了出来，图应该跟代码是一体的，即有了图在去写代码，才能完成完整地将数据的传输过程显示出来，但是我现在连代码都不太懂，图也不知道怎样画才好，是先画图啊，还是一边敲代码一边画图，我想一块来吧，画图，写代码（最近两天将一个登录窗体的代码敲了下，感到很有意思，各种代码格式都通用，那就来吧）。自己没把握把代码敲出来，但是很想试一试。我不知道我需要多长时间来完成，但很想敲下去。一些优点还有可维护性和利于软件的工程管理。这些我想都是由于将将各个功能单位翻开来的结果，不同的层各司其职，每一层不同的应用具有某些相同的特征，是有利于通过工程化、工具化管理代码程序。

       关于分层的暂时就写到这里，估计很快就要写第二遍文档了，接下来画图，通过文档驱动和Rose图在.NET平台上再次完成工程。