13,346
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
haitao5676 2006-07-17
- 打赏
- 举报
多做一做多层的实验就可以理解7层了，不要随便发表意见，做好了多层架构把每一层叫阿猫阿狗都是我做得别人管不着，反正每一层分的时候都有自己的道理，这才叫n层架构，很讨厌拿着一大堆概念在这里说话的人，没有意义嘛！对搂住一点帮助都没有！
Andfly 2006-07-17
- 打赏
- 举报
呵呵 米用过七层的
一直都用的三层
一直都用的三层
haitao5676 2006-07-16
- 打赏
- 举报
我看这里大部分人只是知道多层架构中的一些没有意义的概念，我认为做过多层架构的人很少，会几个概念或者看了几个没有意义的烂熟就开始评头论足了！
haitao5676 2006-07-16
- 打赏
- 举报
七层结构并不是在骗人，也不是在哗众取宠，只是大家都误会了它，而且它也确实有它的迷惑性，大家看看我的帖子吧，就在14层，可千万别在胡说了，7层架构毕竟是个概念，中间最主要的两层当然可以供你随便加它什么随便怎样设计它，但是最终目的是使项目完全的灵活，总之7层架构并不是大部分人为的那样！
mzoy1414 2006-07-16
- 打赏
- 举报
我只听说过网络OSI分七层..NET三层就够了.DA数据层,逻辑层.表示层.
zjh222 2006-07-15
- 打赏
- 举报
NET有这个能耐吗？？
blackhero 2006-07-14
- 打赏
- 举报
七层,传说java大项目可以.
.net没有听说过有分七层 的
在国内三层就够骗了.
.net没有听说过有分七层 的
在国内三层就够骗了.
leishuaiwu 2006-07-14
- 打赏
- 举报
数据库访问层,业务层,显示层.
Just_do_it123 2006-07-13
- 打赏
- 举报
七层?
一般三层的多一些.
数据库访问层,业务层,显示层.
一般三层的多一些.
数据库访问层,业务层,显示层.
zhf777 2006-07-13
- 打赏
- 举报
orz
haitao5676 2006-07-12
- 打赏
- 举报
基于b/s架构基础之上，添加数据访问层和商务逻辑层，这样就成了想在都在风传的7层结构，听起来挺吓人的，其实质就是这样
这里因为b/s架构中的iis的web server层中是个mvc结构，所以有一个隐含的3层结构，所以b/s本身其实就是一个独立的5层结构。
这里因为b/s架构中的iis的web server层中是个mvc结构，所以有一个隐含的3层结构，所以b/s本身其实就是一个独立的5层结构。
以专业开发人员为伍 2006-07-11
- 打赏
- 举报
例如：
想知道.net Framework是怎么分层的，似乎只要看看各个.dll中的模块的相互间依赖关系就行了。这时候就足可以跟人炫耀自己知道大部分常用的.dll之间的依赖关系如何如何。
但是只有去研究各模块内部的各种类型都干什么、有什么联系，才能看懂.net Framework的运行机制。
不过它太大，看懂其中五分之一就是“精通”它了！（当然是看懂构成架构方面的而不是那些鸡毛蒜皮的简单方法）
想知道.net Framework是怎么分层的，似乎只要看看各个.dll中的模块的相互间依赖关系就行了。这时候就足可以跟人炫耀自己知道大部分常用的.dll之间的依赖关系如何如何。
但是只有去研究各模块内部的各种类型都干什么、有什么联系，才能看懂.net Framework的运行机制。
不过它太大，看懂其中五分之一就是“精通”它了！（当然是看懂构成架构方面的而不是那些鸡毛蒜皮的简单方法）
以专业开发人员为伍 2006-07-11
- 打赏
- 举报
当你看到人们（程序员）带着充满憧憬的眼神、口气神秘地去谈论有没有采用“分层”方法去设计软件的时候，往往他们是讲某种“书上”的经典理论。而经典理论都是断章取义地、用几个特意设计的简单类型来说明它们之间的关系以及如何将藕和变得松散。
其实任何.net之下开发的系统都可以根据模块之间的依赖关系来看出分层，只不过要用上述“书上”的那种方法来帮助你看出你的设计蓝图中的各种类型的关系是否可以设计得更加方便灵活。
因此任何复杂的系统都可以看出分了很多层。适当地调整结构，可以将完全“竖井式”的类型结构变成完全“扁平式”的类型依赖结构，关键点不是知道“什么是分层”，而是知道“怎样在功能不变的前提下灵活地改变依赖关系”，以便简化复杂系统的内部结构。
书上的东西总是最简单、最片面的原理性的知识，一般都是适合“经典”而不适合“工程”应用的。
其实任何.net之下开发的系统都可以根据模块之间的依赖关系来看出分层，只不过要用上述“书上”的那种方法来帮助你看出你的设计蓝图中的各种类型的关系是否可以设计得更加方便灵活。
因此任何复杂的系统都可以看出分了很多层。适当地调整结构，可以将完全“竖井式”的类型结构变成完全“扁平式”的类型依赖结构，关键点不是知道“什么是分层”，而是知道“怎样在功能不变的前提下灵活地改变依赖关系”，以便简化复杂系统的内部结构。
书上的东西总是最简单、最片面的原理性的知识，一般都是适合“经典”而不适合“工程”应用的。
以专业开发人员为伍 2006-07-11
- 打赏
- 举报
实际上从比较低且通俗的角度来说，代码模块A和B，如果A模块直接或者间接引用B模块，但是B模块从不直接或者间接引用A模块，这便是A在B的“上层”。
因此在vs开发环境下只要分“项目、工程、模块”都是分层。把那些单纯地脱离实际去卖弄理论名词的东西落地之后才能实用。
如果放在不同工程之中的类型放在（挤在）同一工程之中也是完全可能的，也没有什么不可以，相反则不然。
划分工程，可以从类型之间依赖关系入手，希望不同工程之间类型的关系很少，而依赖比较多、比较明显的类型放在同一工程内部。对于继承关系的类型，很自然地可以放在不同工程中，当然如前所述挤在父类的工程中也可以，这完全是从反映“分析、扩展”的业务模型出发，而不是从计算机编程出发。
在动手之前，拥有设计蓝图，明晰所有类型之间的关系，这是分工程（模块）的唯一条件。
注意，分模块不是分层。分模块更加符合分析设计要求，更加直观地表达模块之间的依赖关系。“管他需要分几层？”，只要分好模块，知道模块之间的依赖关系，“分几层”才确定下来。
对于小型的软件，把别人说的“3层”搅合在一个工程里也许也没有什么；对于大型软件，也许分上二十个工程也觉得不够。
由于系统内部关系复杂，你所采用的开发框架、对系统内部结构的不同认识、用户的“阶段性”修改需求描述、采用的外来模块等千变万化，真正的系统最后会被分几层，是个完全“不确定”的结果。没有看到详细的设计蓝图，谁也不可能正确地说出来。
因此在vs开发环境下只要分“项目、工程、模块”都是分层。把那些单纯地脱离实际去卖弄理论名词的东西落地之后才能实用。
如果放在不同工程之中的类型放在（挤在）同一工程之中也是完全可能的，也没有什么不可以，相反则不然。
划分工程，可以从类型之间依赖关系入手，希望不同工程之间类型的关系很少，而依赖比较多、比较明显的类型放在同一工程内部。对于继承关系的类型，很自然地可以放在不同工程中，当然如前所述挤在父类的工程中也可以，这完全是从反映“分析、扩展”的业务模型出发，而不是从计算机编程出发。
在动手之前，拥有设计蓝图，明晰所有类型之间的关系，这是分工程（模块）的唯一条件。
注意，分模块不是分层。分模块更加符合分析设计要求，更加直观地表达模块之间的依赖关系。“管他需要分几层？”，只要分好模块，知道模块之间的依赖关系，“分几层”才确定下来。
对于小型的软件，把别人说的“3层”搅合在一个工程里也许也没有什么；对于大型软件，也许分上二十个工程也觉得不够。
由于系统内部关系复杂，你所采用的开发框架、对系统内部结构的不同认识、用户的“阶段性”修改需求描述、采用的外来模块等千变万化，真正的系统最后会被分几层，是个完全“不确定”的结果。没有看到详细的设计蓝图，谁也不可能正确地说出来。
jiajiaxiaxia 2006-07-11
- 打赏
- 举报
业务实体层,数据工厂层,数据工具层,数据接口层,数据实现层,业务逻辑层,界面层
阿笨 2006-06-12
- 打赏
- 举报
现在都是流行小高层了
灰太狼 2006-06-12
- 打赏
- 举报
三层就可以了，哪有七层呀，观注中
zjw2004112 2006-06-12
- 打赏
- 举报
哈哈，厉害
狼洋洋 2006-06-11
- 打赏
- 举报
七层楼吧
TCat 2006-06-09
- 打赏
- 举报
7层，楼主要注意安全，那么高容易头晕
加载更多回复（4）
