7,765
社区成员
发帖
与我相关
我的任务
分享无意间小小的理解了三层,散分庆祝
这几天在尝试写一个三层小项目,看了不少源码,博客,问了不少人(感谢CSDN那些回答我问题的人),终于小小的理解了三层了,第一感觉走入了一个新天地,代码还有这么写的,真是太清爽了.
有些人说:小项目不值得用三层,这话我不敢苟同,自己觉得值就行.
网上不少讲三层的很多都是伪三层,甚至他们的代码根本就不能运行.一说三层,就非得有工厂,有接口,恐怕他们自己都不知道在写什么了,或者根本就是从其他地方拷贝来的代码,简直就是误人子弟,毁人不倦啊.初学者要主要分辨.
三层是一种模式,更是一种思想,没有固定标准,只要你写的有数据访问层,有业务逻辑层,有表现层,而且替换掉一层,其他2层不用改,你写的就是三层.
你的代码分项目也好,不分项目也好,都可以,怎样做由你自己判断.
另外,初学者不建议使用代码生成器,生成一大堆无用代码不说,还有不少错误,光是修改生成的代码的时间你就能手写出轻巧的代码了.也不利于学习.我用了一次就马上放弃了,不适合我.
说了这么多,请高手们不要鄙视,也请新手们不要怕困难,大家一起努力吧.
晕倒,只准我发100分的帖子.
有些人说:小项目不值得用三层,这话我不敢苟同,自己觉得值就行.
网上不少讲三层的很多都是伪三层,甚至他们的代码根本就不能运行.一说三层,就非得有工厂,有接口,恐怕他们自己都不知道在写什么了,或者根本就是从其他地方拷贝来的代码,简直就是误人子弟,毁人不倦啊.初学者要主要分辨.
三层是一种模式,更是一种思想,没有固定标准,只要你写的有数据访问层,有业务逻辑层,有表现层,而且替换掉一层,其他2层不用改,你写的就是三层.
你的代码分项目也好,不分项目也好,都可以,怎样做由你自己判断.
另外,初学者不建议使用代码生成器,生成一大堆无用代码不说,还有不少错误,光是修改生成的代码的时间你就能手写出轻巧的代码了.也不利于学习.我用了一次就马上放弃了,不适合我.
说了这么多,请高手们不要鄙视,也请新手们不要怕困难,大家一起努力吧.
晕倒,只准我发100分的帖子.
...全文
请发表友善的回复…
发表回复
皇家玛 2011-09-27
- 打赏
- 举报
楼主建议不敢苟同。
首先 代码生成跟3层没有任何关系。
其次 代码生成更间接，测试用列可以写的更通用一些（自己熟悉的代码生成器或自己写一个代码生成器）。
首先 代码生成跟3层没有任何关系。
其次 代码生成更间接，测试用列可以写的更通用一些（自己熟悉的代码生成器或自己写一个代码生成器）。
aykkk 2011-09-27
- 打赏
- 举报
[Quote=引用 41 楼 juedaihuaihuai 的回复:]
引用 23 楼 moneysoft 的回复:
引用 15 楼 juedaihuaihuai 的回复:
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
既然你使用ORM技术,这样的不良传导是无法避免的,
真正的用设计文档接口……
[/Quote]
能简单说说吗？
引用 23 楼 moneysoft 的回复:
引用 15 楼 juedaihuaihuai 的回复:
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
既然你使用ORM技术,这样的不良传导是无法避免的,
真正的用设计文档接口……
[/Quote]
能简单说说吗？
领衔主演 2011-09-22
- 打赏
- 举报
恭喜楼主啊！！希望大家都继续努力！
saynotome 2011-09-22
- 打赏
- 举报
正在看大话设计模式，顺便求给分
绝代坏坏 2011-09-22
- 打赏
- 举报
[Quote=引用 23 楼 moneysoft 的回复:]
引用 15 楼 juedaihuaihuai 的回复:
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
既然你使用ORM技术,这样的不良传导是无法避免的,
真正的用设计文档接口驱动开发,而不是数据结构驱动开发,
首选是需求变……
[/Quote]
这个还真可以有，提示一下。用ioc就完全可以不动另外两层代码的逻辑。
引用 15 楼 juedaihuaihuai 的回复:
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
既然你使用ORM技术,这样的不良传导是无法避免的,
真正的用设计文档接口驱动开发,而不是数据结构驱动开发,
首选是需求变……
[/Quote]
这个还真可以有，提示一下。用ioc就完全可以不动另外两层代码的逻辑。
whb147 2011-09-21
- 打赏
- 举报
代码生成器都是到了一定的高度后，自己写的
这样才能最适合自己了
可以大幅度提高效率
这样才能最适合自己了
可以大幅度提高效率
ganlu423 2011-09-21
- 打赏
- 举报
不大的项目，个人喜欢用2层，
业务+数据层 UI层。
其实很多时候业务都在存储过程, 所以 有时候数据层也包含业务逻辑。
真真做到BS写的东西拿到CS上，只需做UI，不需要改动任务逻辑.那就说明2层设计合理。
业务+数据层 UI层。
其实很多时候业务都在存储过程, 所以 有时候数据层也包含业务逻辑。
真真做到BS写的东西拿到CS上，只需做UI，不需要改动任务逻辑.那就说明2层设计合理。
小童 2011-09-21
- 打赏
- 举报
专心做码农 2011-09-21
- 打赏
- 举报
接点浮云
xujun5031 2011-09-21
- 打赏
- 举报
怎么一天到晚就是三层？
liuyilin888 2011-09-21
- 打赏
- 举报
MVC跟分层也是两码事
reape 2011-09-21
- 打赏
- 举报
[Quote=引用 25 楼 aykkk 的回复:]
引用 15 楼 juedaihuaihuai 的回复:
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
我只是说小小的理解了,就是刚入门而以,当然不能和纵横各种模式的大牛比了.
三层替换一层不影响其他二层,我的理解是一种平稳过渡……
[/Quote]
呵呵，很多所谓的项目使用年限能超过2年都不错了，我敢说大部份项目从来不会牵涉到数据库和B/S c/S结构的转换。。。这根本不是用所谓三层的理由！！
引用 15 楼 juedaihuaihuai 的回复:
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
我只是说小小的理解了,就是刚入门而以,当然不能和纵横各种模式的大牛比了.
三层替换一层不影响其他二层,我的理解是一种平稳过渡……
[/Quote]
呵呵，很多所谓的项目使用年限能超过2年都不错了，我敢说大部份项目从来不会牵涉到数据库和B/S c/S结构的转换。。。这根本不是用所谓三层的理由！！
vrhero 2011-09-21
- 打赏
- 举报
别急着庆祝，你的理解还差得远呢...
分层是一种工程方法，三层只是一种分层形式...不是什么模式，自然也无定式...MVC跟分层也是两码事...
分层是一种工程方法，三层只是一种分层形式...不是什么模式，自然也无定式...MVC跟分层也是两码事...
aykkk 2011-09-21
- 打赏
- 举报
上面说的漏了dal,dal也需要添加有关这个年龄属性的操作,但是这样的改动是很小的,由于本人刚入门,水平有限,不能完全脱离数据驱动模式开发,对于这个问题也只能这样解决,真正解决这个问题,只有等水平提高了,用真正的用设计文档接口驱动开发来解决了.
ychchhy 2011-09-21
- 打赏
- 举报
有一点理解了！
aykkk 2011-09-21
- 打赏
- 举报
[Quote=引用 15 楼 juedaihuaihuai 的回复:]
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
[/Quote]
我只是说小小的理解了,就是刚入门而以,当然不能和纵横各种模式的大牛比了.
三层替换一层不影响其他二层,我的理解是一种平稳过渡,就是比如,sql数据库换成了orcale,或者b/s的UI换成了c/s的UI,没有更改数据结构,这是一种理想的状态,在现实中不多,因为客户的需求变化是不确定的.不过我想没有那个客户会吃包了没事干,天天要求更改数据结构.
你的问题我这样看:比如用户表,原先没有年龄这个字段,现在客户要求添加这个字段,并且在注册UI中属于必填项,我已经定义了用户实体类,并用于传送数据,这时,我只要改实体类,加个年龄属性即可,业务逻辑并不用变,因为我传送的是实体,不是参数,这就体现出实体的好处了,在UI我只添加一个文本框用于输入年龄数据,赋值给实体的年龄属性即可,这应改是必须的,但你说我改的多吗?
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
[/Quote]
我只是说小小的理解了,就是刚入门而以,当然不能和纵横各种模式的大牛比了.
三层替换一层不影响其他二层,我的理解是一种平稳过渡,就是比如,sql数据库换成了orcale,或者b/s的UI换成了c/s的UI,没有更改数据结构,这是一种理想的状态,在现实中不多,因为客户的需求变化是不确定的.不过我想没有那个客户会吃包了没事干,天天要求更改数据结构.
你的问题我这样看:比如用户表,原先没有年龄这个字段,现在客户要求添加这个字段,并且在注册UI中属于必填项,我已经定义了用户实体类,并用于传送数据,这时,我只要改实体类,加个年龄属性即可,业务逻辑并不用变,因为我传送的是实体,不是参数,这就体现出实体的好处了,在UI我只添加一个文本框用于输入年龄数据,赋值给实体的年龄属性即可,这应改是必须的,但你说我改的多吗?
z_f_p 2011-09-21
- 打赏
- 举报
恭喜，接分~！
--缪军-- 2011-09-21
- 打赏
- 举报
[Quote=引用 15 楼 juedaihuaihuai 的回复:]
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
[/Quote]
既然你使用ORM技术,这样的不良传导是无法避免的,
真正的用设计文档接口驱动开发,而不是数据结构驱动开发,
首选是需求变化,引起文档变化,如果文档接口并没有改变,
三层里的任何层都不会变化,
比如说要为客户信息增加一个Description字段,这个要求不会导致任何代码迭代
楼上说的数据结构变化会导致dal修改更是不可能了,
dal是通用的,不可能出现任何数据相关的内容
真的理解了么？提个问题，如果orm过来的实体里增加了一个属性（这里只是数据库结构发生了改变，理论上只需要更改DAl），而这个属性又是要在ui里使用的。那么楼主怎么做到只更改dal，不动其他两个层的代码呢？
[/Quote]
既然你使用ORM技术,这样的不良传导是无法避免的,
真正的用设计文档接口驱动开发,而不是数据结构驱动开发,
首选是需求变化,引起文档变化,如果文档接口并没有改变,
三层里的任何层都不会变化,
比如说要为客户信息增加一个Description字段,这个要求不会导致任何代码迭代
楼上说的数据结构变化会导致dal修改更是不可能了,
dal是通用的,不可能出现任何数据相关的内容
li2422121715 2011-09-21
- 打赏
- 举报
同喜同喜，红包拿来
--缪军-- 2011-09-21
- 打赏
- 举报
1.支持楼主的观点
2.有一种恒定三层:MVC
M:提供者
V:消费者
C:代理人
在系统的任何粒度上,都可以用这种模式区划分职责,隔离变化
2.有一种恒定三层:MVC
M:提供者
V:消费者
C:代理人
在系统的任何粒度上,都可以用这种模式区划分职责,隔离变化
加载更多回复（25）
