三层架构问题~~~~~~~~在线等高手下边的程序为加学生或者老师，有2中写法，但是我不知道改用哪个？Class 表Cla
三层架构问题 ~~~~~~~~在线等高手
下边的程序为加学生或者老师，有2中写法，但是我不知道改用哪个？
Class 表
ClassID
ClassName班级名称
People表
PeopleID
Flag 标志，1,学生；2,老师
Name 姓名
Sex 性别
V_Student 视图
Name
ClassName
Sex
V_Teacher 视图
Name
ClassName
Sex
第一种写法
C# codeWeb层 addStudent.aspx.csprotected void btnAdd_Click(object sender, EventArgs e) { StudentInfo info = new StudentInfo(); info.Name = txtName.Text; ...... if (StudentBLL.AddStudent(info)) { JScript.AlertAndRedirect("添加成功！", "ManageStudent.aspx"); } }addTeacher.aspx.csprotected void btnAdd_Click(object sender, EventArgs e) { TeacherInfo info = new TeacherInfo(); info.Name = txtName.Text; ...... if (TeacherBLL.AddTeacher(info)) { JScript.AlertAndRedirect("添加成功！", "ManageTeacher.aspx"); } }BLL层(StudentBLL.cs) public static bool AddStudent(StudentInfo info) { if (instance.AddStudent(info)) return true; else return false; }(TeacherBLL.cs) public static bool AddTeacher(TeacherInfo info) { if (instance.AddTeacher(info)) return true; else return false; }DAL层(StudentDAL.cs) public bool AddStudent(StudentInfo info) { StringBuilder buffer = new StringBuilder(); buffer.Append("insert into People(Flag,Name,Sex) Values (@Flag,@Name,@Sex)"); SqlParameter[] parameters = { new SqlParameter("@Flag",SqlDbType.Int,4)...}; parameters[0].Value = 1; ... SqlDbHelper db = new SqlDbHelper(); return db.ExecuteNonQuery(buffer.ToString(), CommandType.Text, parameters) > 0; }(TeacherDAL.cs) public bool AddTeacher(TeacherInfo info) { StringBuilder buffer = new StringBuilder(); buffer.Append("insert into People(Flag,Name,Sex) Values (@Flag,@Name,@Sex)"); SqlParameter[] parameters = { new SqlParameter("@Flag",SqlDbType.Int,4)...}; parameters[0].Value = 2; ... SqlDbHelper db = new SqlDbHelper(); return db.ExecuteNonQuery(buffer.ToString(), CommandType.Text, parameters) > 0; }DBUtility层StudentInfo.cs...TeacherInfo.cs...
第二种写法
[解决办法]第二个！
[解决办法]你可以看看代码生成器生生的代码
！！！
[解决办法]第二种 同样的方法没必要写2个
[解决办法]5楼的办法不错。。。
[解决办法]第二种，就跟商店里的食品一样，难道 添加猪肉跟牛肉 要写2个方法。
[解决办法]楼主这个问题难有标准答案
因为楼主是想对学生和老师对象进行抽象，抽象出People这个基类，
People可以是interface，或者abstract class，也可以是class
但要不要对People做持久化，这个需要根据实际情况来做具体设计。
如果要我来做，会分别建学生表和老师表，而people只会做为一个抽象对象存在，
楼主现在的做法实际上把学生和老师对象在数据库层面上就耦合在一起了，不利于以后这两个对象独立的变化。
[解决办法]那个简单用哪个
[解决办法]这两种都挺差劲的。
[解决办法]动软生成器，有用过么？下个用下就可以看到效果
------解决方案--------------------
第二个
[解决办法]bll 层写方法的名字和参数以及返回值
dal 方法的具体实现
[解决办法][解决办法][解决办法]LZ想知道什么不太清楚。三层结构就是、层次清晰、易于管理。 数据访问层 DAL 逻辑层BLL 表示层 Web 。
写法随意，一般不大的项目我是用 简单工厂模式加三层结构，在复杂就多层结构。
[解决办法]从你的问题中可以看出，你也是那种为了三层而三层三层的思路的受害者。这个时候追求所谓三层的“型”，但是你根本没有认真分析“实际业务应用领域”的业务逻辑到底是什么。除了“增删改查”你就不知道什么是真正的业务逻辑了？！
那么这时候不必去太在意所谓三层。如果你想做一个设计师，去多多理解不同的可能端开发的可能性，等有了经验再来进行业务逻辑封装。现在你就直接在表现层去调用DAL层好了！
[解决办法]楼主的意思是该不该将学生和老师分别进行抽象。
个人认为如果学生和老师存在许多不同的业务，那么在BLL层应该独立，但可以共用一个DAL层，因为数据结构是相同的，但业务逻辑可能不同。
需要说明的是，在COL层和DAL层可以分别只有：PeopleInfo和PeopleDAL
但在BLL层可以有两个BLL:StudentBLL,TeacherBLL，都对COL层和DAL层进行调用，但可以有许多不同的业务逻辑方法，如:
StudentBLL.Upgrade(PeopleInfo student)//学生升级方法
TeacherBLL.AddMoney(PeopleInfo student)//老师增加工资方法
当然这其中可能还会涉及到班级和工资对象及数据表。然后界面层根据应用对StudentBLL和TeacherBLL进行调用，业务上会很清楚，代码也不会很冗余。
另外，我也不觉得楼主是什么“为了三层而三层三层的思路的受害者”，能思考这样是否合理，本身就已经不是死板的套用了，这觉得这种思考是值得鼓励的，这种思考是可以有效提高软件系统质量的。
代码生成器不是万能的，当然不可能生成业务逻辑，但是数据实体与访问的代码，或者界面还是可以生成的，这在开发中的确可以节省大量时间，所以代码生成器也不是一无是处吧？
另外楼主也可以试试这个代码生成器，是我和朋友历时一年开发出的代码生成器，名字叫EasyCode功能绝对强大，里面采用了更加面向对象的三层架构：
http://blog.csdn.net/cwbugs/article/details/7268267
[解决办法]就从你贴出的代码来看，所谓的BLL完全是自己蒙自己，简单地重复了一下DAL而已。删掉BLL代码算了。
[解决办法][解决办法]那些推销什么“生成器”的人必然给你对消为了三层而三层的所谓“设计”。你想啊，除了这个办法，他还有什么办法呢？因为现在的所谓“生成器”半点也不懂你要的业务逻辑啊！
如果你把精力都投入到这种扭曲的三层的概念中，将来真正需要三层架构的时候，你的时间和精力都花在错误的地方那个上了，根本无法高效率地进行系统设计和与沟通（因为你可能会听到一点新的设计想法就去纠结“增删改查怎么写”的沟里去了）。
等你稍微多一点经验，你会真正遇到需要跨6、7个数据库表的一些操作，甚至经验和水平再多一点，则重点根本不是什么从数据库存储出发而是从通讯方面出发。这时候再来看你的仅仅围绕“增删改查”的所谓“三层架构问题”，就会觉得很无奈了。对这个低级的编程应该放弃纠结，以任何方式编程都可以，而不用纠结与“要么是一、要么是二”。
[解决办法]可不可以解释下，怎么扭曲了呢？
这样设计怎么就不影响了“高效率地进行系统设计和与沟通”呢？
现在如果这些基本的三层架构不去掌握，何谈以后所谓的“需要跨6、7个数据库表的一些操作”？
DAL层也未必一定是数据库存储啊？
另外这个“对这个低级的编程”，这显然是在对面向对象的实际使用进行讨论，怎么就低级了呢？
[解决办法] 现在基本上都是用动态生成的了。
[解决办法]第二种好点。。代码重复是很没必要的事情，要不然你重构的时候还要改
[解决办法]BLL不是对CRUD操作的再次封装，而应该是业务逻辑的集中表达。BLL中每个类的职责，应该是业务逻辑的具体反映。
BLL应该是PI的，这样即便没有数据库的支持，BLL仍能保持其独立性和完整性。BLL的类，不能与数据库的表划上等号。同样的，BLL的事务，也不能与数据库的事务划上等号。
DAL_A，BLL_A，PRT_A这样的一个层次关系，通常很难完整和准确地表达并实现业务需求。
[解决办法]第一种，你应该记着一条。
一个设计师理论上不应该去让你的调用者，去记忆一个数据调用规则。
没有任何理由说，前端调用的人在使用的设计的东西，就应该去记着
Flag 标志，1,学生；2,老师
这不是调用者应该记忆的事情，这类东西本身就应该封闭在对象内部。
另外你的系统也没有任何理由去依靠一个数据库结构。谁说这些人员一定需要放在一张表里，并且用flag标识？？？难道我们不可以一个类型一张表？？或者放在xml里？？
------解决方案--------------------
接口层（通过接口层调用数据层）：
C# codepublic interface IStudentBLL{ bool AddStudent(StudentInfo info); bool AddTeacher(TeacherInfo info);}
[解决办法]
Web层：
C# codeaddStudent.aspx.csprotected void btnAdd_Click(object sender, EventArgs e) { PeopleInfo info = new PeopleInfo(); info.Name = txtName.Text;info.Flag = 1; ...... if (PeopleBLL.AddPeople(info)) { JScript.AlertAndRedirect("添加成功！", "ManageStudent.aspx"); } }addTeacher.aspx.csprotected void btnAdd_Click(object sender, EventArgs e) { PeopleInfo info = new PeopleInfo(); info.Name = txtName.Text;info.Flag = 2; ...... if (PeopleBLL.AddPeople(info)) { JScript.AlertAndRedirect("添加成功！", "ManageStudent.aspx"); } }
[解决办法]
接口层改下：
C# codepublic interface IStudent{ bool AddStudent(StudentInfo info); bool AddTeacher(TeacherInfo info);}
[解决办法]
每天回复既有10点积分。
[解决办法]
petshop写的不错，有了接口还不够，还有反射过去才行，一般在webconfig中映射
[解决办法]
第二个
[解决办法]
因为这只是简单列子，所以看起来第二种好
但是，按严格来说，你还应对传人的值，做判断，比如你的数据某个字段长度是4，而传人的大于4，就会报错，你应该在bll里处理，第一种比较规范
[解决办法]
对于小项目来说意义不大。当情况不同，用的模式就不同，固化的三层就要作改变了。对于理解语法概念，是一个比较好的学习例子。
[解决办法]
怎样搞才不是为了三层而三层？
[解决办法]
倾向于把老师和学生看成是同一类，那就是同一种业务逻辑，只是权限不同。新添加一个人，可以给老师和学生两种不同的权限。
[解决办法]
[解决办法]
25和26楼的回复真有趣！！！问题都是讨论出来的！！谢谢分享哈！
[解决办法]
-, - 没大区别 bll等于虚设
乃这个需求直接把业务逻辑和页面逻辑分开就可以了 至于其它的扩展得看你的需要吧
[解决办法]
[解决办法]
要预留变化，但也不能为了预留变化而预留变化。什么事情都要有个度。一般设计，学生和老师都会直接分开存，不会放一起的，因为他们所需要的属性和关注点都不一样的。（如果把老师和学生看做一种，只是简单分类的例外）。
[解决办法]
BLL和DAL分开是必要的，即使这里是简单的调用，因为如果需要，会在BLl加其它逻辑的。必须校验之类的。
[解决办法]
[解决办法]
[解决办法]
好像没看到有什么区别，
这两种都不太好，尽量少的使用返回值，依靠异常来处理。
分层分的太厉害了，耦合度什么的没看出来，至于将来的事务处理，好像这样也做不到
[解决办法]
我觉得在设计方面，c#应当多借鉴java的一些设计思想，不应当凭空的想象应用场景。
在大型项目的分层设计上，是为了分担压力而进行分层设计，采用EJB等框架进行业务压力分担。
但是一个teacher和student的项目，一看就没有必要这么做。
c#的项目这么做必要性不是特别大
[解决办法]
if (bool)
return true;
else
return false;
}
好囧
[解决办法]
数据访问层和业务逻辑层是肯定要分开的，虽然基本的逻辑在很多单表的情况下BLL似乎只是简单的调用DAL，但毕竟只是一部分，BLL处理业务逻辑，比如合法性检查，关联数据操作，事务处理等。而且更为关键的，BLL和DAL分离，使得BLL真正的脱离了数据操作，那么后面的数据是分布式存储，是数据库存储还是文件存储，或者是外部服务获取等都获得了极大的扩展性。过度分层是没有必要，但BLL，DAL，DBhelper分离是最基本的分层，而不是什么过度。
分层一定要有很强目的性的：dbhelper可以抽象异种数据库访问，或者分布式数据库访问。DAL则可抽象数据访问，使得改变具体数据来源变得透明。这在分布式模式下非常的有用。
[解决办法]
数据访问层是针对数据的，因此最好要收紧数据访问接口，如果数据是数据库的，那么数据访问层最好是针对数据库对象，而不能针对业务对像（你的例子把老师跟学生看成了两个业务对象，如果处理逻辑确实不同，这样处理是可以的，但这种情况下你的实体类还是Person，你的方法名或者参数名可以区分老师和学生，一般情况下不赞成实体做过多的层次结构，因为通常情况下，实体是对应数据库对象的）。
实体，实体访问层(数据访问层)，业务逻辑，数据库访问层，这种情况下，实体是原料，数据库访问是通道，实体访问是运输，业务逻辑是加工，典型的现代工厂模型。
[解决办法]
[解决办法]
深切体会到 sp1234 的话。
[解决办法]
[解决办法]
每次看sp1234的回复都会觉得受益匪浅啊
[解决办法]
[解决办法]
认真看了回复,受益匪浅！
[解决办法]
[解决办法]
当然是第二种啊。只是一个flag不一样..不必写两个//
[解决办法]
接分闪人……
[解决办法]
第二种
[解决办法]
三层架构本就是为了分离表述层和数据层的，中间的业务逻辑是两者的桥梁
[解决办法]
[解决办法]
