数据库和业务层都可以实现业务逻辑.....那如何分配业务呢
数据库里可以用存储过程实现业务逻辑,软件的业务层一样也实现业务逻辑，
那到底怎样设计业务层呢，哪些逻辑该放在数据库里实现，哪些放在上层，。。。。我该如何设计呢。。。

大家给我指点迷津吧

------解决方案--------------------
说一下我浅显的理解吧 希望对你有帮助
ui bll dal model
ui就不说了，就是界面，去调用bll层
bll层就是业务逻辑层，调用dal层
dal只负责处理数据 在dal层写sql语句
model 一般就是数据库中表对应的实体类 一般数据库中有几个表 model层就有几个类（不绝对）

举个简单的例子。。。
比如有个业务是判断这个id是否存在 如果存在则进行更新 如果不存在就进行插入。

那么dal层 需要有三个方法 一个是判断是否存在的方法 另一个是插入的方法 第三个是更新的方法

而在bll层只要有一个方法就足够了 这个方法就是分别调用dal层的三个方法。
------解决方案--------------------
与其纠结所谓的三层，还不如多看看开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则这些呢
------解决方案--------------------
基本上，DAL层就是围绕着数据库操作，相对于数据库操作来说是“很好的封装”，而相对于BLL来说它是属于“闭门造车”的无关层面。所以叫做DAL层。

如果你根本没有兴趣去封装DAL，那么就顶多写一个SQLHelper类库提供几个简单地提高编写Sql的效率的方法就行了。注意，根本没有必要围绕着什么实体类、数据库表去编写DAL代码。

而设计BLL层，需要真正抛开数据库表那种低级的东西，真正去理解业务流程、与前端的时序周期、数据安全性、业务功能的里程碑（不可能本次就完成以后才能完成的所有功能）等。这种时候你就是在设计BLL层代码。
------解决方案--------------------
对于分层也一直很纠结
BLL,DAL,这样分层在分工合作上比较方便
但实际上这样做在一定程度上会影响运行效率
有些业务逻辑比较复杂，写在后台数据库执行效率会比较好
但不同的数据库语法又不一样。
不过还好本人想得通，以解决问题为目标。
------解决方案--------------------
举个例子 用户登录
一般就是先查用户名是否存在 然后再是密码是否正确
DAL可以写一个GetUserByUserName 返回一个User
在BLL里面 你通过调用GetUserByUserName返回的User来确定这个用户登录的逻辑 首先返回值是否为空确认用户名是否正确，密码是否和User的密码吻合确认密码是否正确
这里有一点 就是分层时候讲到的松耦合 如果这个逻辑我们都写到Dal里面 那么我们如果换数据库 势必要把DAL重新写重新编译 而如果我们分开来 那么只要把DAL代码变下 只要返回的还是User， BLL的代码是不用动的，这里最重要的就是 BLL不知道DAL是怎么给他数据的 他只要知道DAL可以给他数据就可以了
甚至于可以更进一步 设立IDAL的接口，BLL的调用都改为针对接口，那么以后你就可以通过依赖注入，通过改配置文件的方式不改代码直接就把底层数据操作的代码全部改为针对另一种数据操作的代码

探讨

引用:

如果你是Oracle产品的粉丝，自然就会因为什么都在数据库里去写代码。别忘记了，数据库里去写java代码啊，这还叫做数据库吗？其实完全是混淆概念。

基本的数据库，就是实现磁盘分配、记录存储、索引、sql编译执行、事务操作、分布式操作等有限的数据库功能，而不是搞什么数据库中的编程概念。

当然你喜欢把代码都用存储过程去写，甚至就算是写个四则运算、取个系统……

------解决方案--------------------
跟数据库打交道类放数据访问层，处理逻辑的类（与UI层没有太大依赖关系），一般是返回DAL层的方法或者一些判断等放在业务逻辑层，UI层就是调用业务逻辑层的方法。Model层，实体层说白了一般就是根据数据库字段封装的类，一般用在List<Model>存数据。UI引用BLL，Model。BLL引用DAL，Model。DAL引用Model。UI层就是取得数据用数据。所以一般业务逻辑写到业务逻辑层。