关于VB的三层

当时看了一下用VB开发三层结构的程序，当然VB这种基于对象的编程语言开发三层有些先天不足，不过呢，用用也可以。现在又多了一些问题三层简单分为UI，业务和数据库访问层。当时将做了ORM映射的类写在了业务层。例如，我有个Students的数据库，则业务层有两个类模块cStudent,cStudents。当时好像一些示例都是这样的。但现在看了一些其它语言的三层，发现他们一般将这些类独立出来，不属于三层中的任何一层，通常叫做实体层（Java中好像也叫实体Bean）。个人感觉也应该这样。但为什么当时CSDN VB版中，未讨论这个层？还有网上下载的程序也把这些类放在了业务层？还是VB只能这么做？

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

（1）先双手接分
（2）业务层可以以DLL的形式，通过UI去调用，也可以单独做一个中间层啊，有什么问题吗？放在中间层服务器上，以winscock形式接收客户端的数据请求，同数据库服务器上的DB连接，处理完后再返回客户端。
（1）再次双手接分
就不给分:)我的意思是说，当时这么多高手谈VB中开发三层，为什么都把这些实体放在了业务层？而PetShop或Java都把实体独立出来，并没有放在业务层。
（2）业务层可以以DLL的形式，通过UI去调用，也可以单独做一个中间层啊，有什么问题吗？放在中间层服务器上，以winscock形式接收客户端的数据请求，同数据库服务器上的DB连接，处理完后再返回客户端。貌似不知道DCOM是何物你可以把实体单独写开，工作量是个问题
呵呵，用Winsock还是DCOM反正不是我想问的。当然，我认为实体应该放在一个独立的层，这个层不属于三层中的任何一方，如Duwamish7中就多了个Common。但我想知道，为什么当时的VB程序员都不把实体放在单独层中，而放在业务层中。其它程序员如Java就不这样做。  是不是有什么深层次的原因？害得我看Duwamish中的Common看了很长时间。网上下的VB三层好像基本都把实体放在业务层中，很想知道为什么
TO楼上：
貌似不知道DCOM是何物
---------------------
不是貌似，我是真不懂啊，你来讲讲吧。
to lz:
大家把自己的数据访问层以及封装数据的代码贴出来，你也把JAVA相关的代码贴出来对照一下，应该很快有答案的。
楼主怎么那么死板呢？不要为了分层而分层，怎么分都是实际需要
为什么不能把实体放在业务层中？
我现在做的一个.NET项目就是把实体放在业务层中的，只不过是单独的一个目录而已
有必要分一层出来吗？
如果你认为有必要先说说有什么好处，不要人云亦云~
以前我们有个VB项目是把实体层分出来的，一个单独的DLL
是因为有多个项目要用到；
如果只是业务层本身用的话，有什么理由分出来？
/*
为什么当时的VB程序员都不把实体放在单独层中，而放在业务层中。其它程序员如Java就不这样做。
*/
VB做的是C/S程序，Java做的是B/S，运行机制不一样的，有可比性吗？
viena(维也纳nn)讲得很清楚啊。JAVA偶不懂，乍一看LZ的问题，确实不能理解，哈。
LZ：还可以接分吗？嘿嘿
倒，都这么喜欢分啊。看来重赏之下，必有勇夫。
记得三四年前，问问题的基本上都是80或100分的，后来发现怎么都小气了，都是20分给了。
fyming(农妇,山泉,有点田)：呵呵，兄弟能进来打上几个字帮忙，当然有分了。DCOM就是指如果我将一个DLL部署在A计算机上，B机上的程序能够直接调用A机中这个Dll中的功能
viena(维也纳nn)：感谢你的回答。本来我在VB中这么用，也没什么问题，但……
根据分层规则，界面层调用业务层，业务层再调用数据访问层。但不把实体分离出来，数据库访问层要用实体层的类该如何处理？总直接使用业务层的实体，那就变成数据库访问层也调用业务层的代码了。如：function FindStudents(Condition as String) as cStudents
         '访问数据库
    end function    function UpdateStudent(stu as cStudent) as Boolean
         '访问数据库更新学生
    end function
这样一来，数据库访问层将反向调用业务层中的cStudents类了啊
（1）先谢谢LZ的分啊，其实CSDN的分又算什么呢？当不了钱花，我今早又散去了200分，能让大家高兴一下，何乐而不为呢？很多网友来CSDN的目的，一方面是学习，另一方面是因为好玩，就象是在TOM或者联众下棋一样，挣分，升段，仅此而已。
（2）也谢谢LZ对于DCOM的解释，其实说句实话，有些话LZ是不必过于认真的，就好象我和杰西问您伸手要分一样。
我说过了，具体放在那里看是实际需要；
如果你有一个独立的数据访问层，确实需要分出来；
但不分出来也同样是可以的，没有什么好质疑的；
比如我们现在的一个.NET项目，就向你说的一样没有数据访问层；
数据访问在业务层中完成（数据对象，调用ORM)
呵~~讨论到这么激烈,我也来插句嘴吧!首先我先说明下,我不是什么高手,特别在编码上,基本上是没帮助,没网络什么都写不出来,不过我是一个项目管理者,研究的是软件工程,所以对结构上稍有些了解...如果有什么说错的地方,请不要大骂:)好了,下面说说我对LZ的问题的经验与见解吧:
首先我先指出一点,上面有说VB是C/S,JAVA是B/S,是错的...VB也能B/S,JAVA也能C/S.看你怎样写,我看过一个最牛的是有个日本公司的JAVA程序员用流式(C传统写法)来完成一个财务系统....我感叹了一晚..嘿嘿!~~VB天生是面向过程的语言,JAVA则是对象.而JAVA本身就只有类这概念...VB则不是.JAVA的BEAN其实是一个对象集.他有点像VB的COM,但两者不同的地方在于BEAN能单独使用,COM不能...COM是跨语言使用,但BEAN是跨平台,这也是两个开发语言本质的区别吧!好了,说到这里,LZ应该知道为什么JAVA会把实体层独立出来,而VB不能了吧(其实不是不能,而是没必要)?如果还不明白,请继续往下看(懂了就指出看法与错误就行了):
BEAN其实也是一个组件(跟COM一样,区别上面说了),而组件又分可视化组件(如按钮)与非可视化组件(如TIMER).可能有人会问,那跟VB没区别啊,VB其实也可以把实体层独立出来使用,为什么不这样呢?其实BEAN在JAVA机制中并不完善(JAVA的模式一),特别体现在B/S,分布式开发中...在JSP开发中,根本就体现不出真正的三层,跟ASP一个样,HTML代码与程序代码完全不能分离.所以到了JAVA的模式二中(MVC)就完全解决了这个问题.BEAN在这里的使用也只是一个摆设(其实也挺重要,不过跟原来意义大大的改变了),在模式二中,一个类就会带一个BEAN(有时候会两到三个,但不会多),通常都是用来放属性(GET,SET)和一些小型接口的.好了,好像扯远了...在VB6这过程中,实体层意义根本就不大,分离出来作用不大(可能会影响效率,因为每多一个类都会耗比较多的资源),他既不能单独使用,就算是重用,也可以直接分装为COM组件.好了,大体解释完了...看完的朋友可以说说见解跟指出错处了!!