问题描述
news.aspx.cs--表示层---------------------------------------------bllbll=newbll();sllsll=newsll();protectedvoidPage_Load(objectsender,EventArgse){//获取新闻绑定id=sll.isint(request.querystring["id"]);//验证是否数值型newslist.datasource=bll.get_newslist("news",id);newslist.databind();//删除新闻bll.get_newsdel(sqlstr);}bll.cs-业务逻辑层----------------------------------------------daldal=newdal();datasetread;publicDataSetget_newslist(stringtablename,stringid){read=dal.execute_sql("select*from"+tablename+"whereid="+id+"orderbyiddesc");returnread;}publicvoidget_newsdel(sqlstr){try{dal.exe_sql(sqlstr);...//这里提示删除成功}catch{...//这里提示删除失败}}dal.cs-数据访问层----------------------------------------------datasetread;publicDataSetexecute_sql(stringsqlstr){using(SqlConnectionconn=newSqlConnection(connection())){//用存储过程执行sqlstr并获取readreturnread;}}publicvoidexe_sql(stringsqlstr){using(SqlConnectionconn=newSqlConnection(connection())){//用存储过程执行sqlstr}}不知道以上3层设计是否可行请大家指点一下
解决方案
解决方案二：
我是认为,三层架构是表现层完全是页面东西逻辑层只是负责连接表现层和数据层的东西所以数据访问层里应该是放一些存储过程或者SQL语句之类的东西而且SQL操作类最多只是算数据访问层的帮助类,这样理解有无问题?
解决方案三：
这个目前的分歧较大.
解决方案四：
个人理解不一样，说法也太多了
解决方案五：
1.业务逻辑层里不要出提示信息,返回值到表现层就行了.2.出现异常要写日志
解决方案六：
up
解决方案七：
这方面的讨论实在太多业务逻辑层最好不要有SQL，只负责传参数，这个应该在数据层处理
解决方案八：
这跟我们公司现在的有些类似，但是如楼上所说，业务层出现异常是返回失败信息给表现层，让表现层显示提示信息，另外我们的数据访问层不直接写sql，而是用存储过程，我一直觉得我们的3层结构有点奇怪，但又说不出哪里的问题，可能是由于直接依赖于数据库的模式，修改维护很不方便
解决方案九：
read=dal.execute_sql("select*from"+tablename+"whereid="+id+"orderbyiddesc");-------------------不要这样bll最好是调用数据访问层的函数,传递参数
解决方案十：
我UP吧，各人理解不同，写出来的也不同
解决方案十一：
read=dal.execute_sql("select*from"+tablename+"whereid="+id+"orderbyiddesc");-------------------不要这样bll最好是调用数据访问层的函数,传递参数--------------------------------------------------------------能具体解释一下怎么传递参数么
解决方案十二：
还行
解决方案十三：
查询的工作交给数据层函数去做,比如table,id等变量,提取出来作为查询函数的参数,返回结果集.增删改查交给数据访问层,这样子易于修改和维护.当然,具体问题还需要具体分析.业务逻辑复杂,建议这么做
解决方案十四：
认同：yfqvip(逝水无痕)的观点
解决方案十五：
up
解决方案：
还不够细，业务层做了不属于它的工作
解决方案：
在.net中很难完全分开的啊，原则上逻辑一类的都要在了逻辑层中处理掉，可现在真正做的时候，很多逻辑还是在页面上处理的，逻辑层仅仅用来传递数据了
解决方案：
其实这个主要看个人的理解了，只要可维护性高，耦合性低就可以了
解决方案：
主要是逻辑层难分...呵呵,偶尔会觉得逻辑层有点多余,偶尔又会觉得少不了..啊门