逻辑层的问题！

Question

各位大侠，我现在要写一个逻辑层，逻辑层的类是按表区分，还是按功能区分？还有一个问题，我的data层只是操作数据库返回值，就是逻辑层传命令结构体，返回数据集结构体。SQL语句和业务限制都在逻辑层中编写，这样会有问题吗？

Answer 1

晕，先把以前的帖接了再说！
然后：
逻辑层是按照表来区分。sql语句和业务限制都在逻辑层编写？？？
我晕。我怀疑最简单的三层懂不懂啊业务限制一般都在前台写的。逻辑层一般都是写方法名的。data就是实体层就是写sql语句的。这些是最简单的三层了···

Answer 2

没明显界限
-----------
你认为是一个原子操作就放在数据层。是一个功能原子操作就放逻辑层。sql也可以包含逻辑。------------
往往看是不是一个事务操作来断定放入which tier！

Answer 3

我就是觉得逻辑层只是重复调用Data层的函数，意义不大~而且效率很低。如果是一个表一个类的话，那么表与表之间的连接查询怎么处理？

Answer 4

       效率低？那样看你连接数据库的次数啊，你连接上百次当然慢了··对数据库连接的越少越好···
如果要关联表，关键是看你的表需要什么····一般小项目左联表即可。。join left 这样就可以达到索引2张表了

Answer 5

那就好像Class表和Grade表之间的关系，根据Grade找class，这个函数应该写在class类还是grade类？

Answer 6

MVC
一：用户逻辑（页面逻辑）
二：业务逻辑（访问数据库）
三：实体类（数据库对应字段）

Answer 7

业务逻辑层要从界面需求出发去设计接口，
设计一整套业务层接口功能，只要考虑UI层与业务逻辑层，涉及中间的实体数据模型，
而不需要考虑数据库
DAL与时具体业务分离

Answer 8

关键是你要找什么····我还是建议你学一下sql语句好点     比如classID写入Grade里面。那么  grade 就有响应的classID。所以就有 select * from  classID as a join left grade as g on a.ClassID=g.ClassID 就可以找到你要用的数据···后面还可以加上条件的。。

Answer 9

当然是功能。逻辑层设计时，完全不考虑数据库表的，不然怎么会分出高低呢，低层的用来实现高层的，高层的用来对表现层彻底隔离那些阻碍它写出好的交互程序的杂乱和纠结的东西。设计表现层时完全不考虑“数据库是什么”的问题，应该假设根本不使用数据库来实现。如果你的数据库很少改变，要求也不高，使用sql语句也是可以的。只不过要考虑开发的效率问题，使用一些比较好的sql helper之类的就可以了。说白了，为了设计出好的客户端程序，核心就是将表现层跟数据库分离，这就是三层。这个观念最重要，而至于具体低层的写法则是其次的。

Answer 10

嗯其实，基本上你尽可能多做一些远程、网络软件，一个业务服务系统，给几十个繁忙的终端提供业务数据处理支持。这样，三层的概念非常清楚。你也就可以非常容易理解如web service、SOA等等概念为什么会在前几年火起来。如果整天做单机软件，或者asp.net这种看似只有一个客户端的软件，其实难以了解网络应用的需求。

Answer 11

我几乎没有什么小程序代码。偶尔需要写个demo，一般只用10几分钟，写完、发出去之后就丢弃了。比较实际的程序，哪怕只有几十行，往往都是放到上百万开发费的项目中作为比较核心的引擎用的。其实许多东西就是因为你已经提出来了，我只是给你一个确认而已。我的目的并不是让外人能看懂，所以你也没有必要一定要我给一堆垃圾代码用来模仿。我看到你自己其实已经写出来了，只是缺少在努力几分钟就能做好的关键环节，我只是给你个建议而已。
设计不是看代码，用一张纸画一画你的表现层跟业务服务必须进行什么通讯，就行了。比如银联卡的提款机，它肯定要到银联的服务器上去验证用户输入的密码是否正确，它不能自己说了算。你按照系统分析的思路，把不同的系统接口，它们之间交互的消息交互行为（UML中叫做时序）搞清楚，有20个就算20个，有100个就算100个，这就是业务逻辑层要提供的服务功能。有了细节，了解涉及不同子系统的什么角色，实体的结构是什么，才分类。而不是从别人那里听个什么类的概念，然后自己死抠、分解细节。难做到的就是，许多人不去花心思写清楚必要的交互细节，就去搞概念了。服务是独立的，一套设计独立的好的服务，往往可以支撑起上百个不同种类的客户端软件。客户端软件千变万化，而它们都可以靠同一套业务逻辑服务来提供给不同的人，看似不同的应用系统，甚至运行在不同的硬件平台上。所以业务逻辑服务不是跟应用的窗体，或者非常低端的数据库表之类的一一对应，重点是从分析表现层再千变万化时到底需要什么样的业务服务，与之交互的一步一步过程是怎样么样的，然后独立地编写业务服务代码。你把业务服务代码所在的工程（或者说是与其通讯的代理工程）引用到其它表现层的程序工程中，也就立刻可以被其它客户端系统使用同一套服务了。

Answer 12

其实你是个学生没有必要考虑这么多，SP的答案你能明白就明白，不明白没有必要去死扣概念
设计模式很多种，你在具体的实践中多做，你自然会找到一些好的设计方法，这就是设计模式
PS：业务逻辑层就是处理业务的，基本就是对功能的实现，简单来讲就是写通用的功能块被重用