浅谈三层架构中的实体类(C#)

最近因为三层架构中的实体类，引发了不少小问题，下面列举一下，谈谈自己的感想。

本文所指的实体类仅限于三层中的实体类，即数据库表的映射。

一、为什么要用实体类？

| 使程序简洁易懂，便于维护。

| 暗合接口不变原则。

| 体现面向对象思想。

举例说明：

不用实体类的三层

假如程序有所变动，需要增加一个参数，学生年龄

用实体类的三层

同样增加一个参数，学生年龄

很明显的看出，用实体类之后，代码明显变得简洁，面向对象封装思想。

最重要的是，如果将来有所改动，只需要改动实体类，方法间调用接口，完全不需要变动，大大减少了程序修改量，迎合了面向对象中接口不变的思想。

甚至在程序设计时，就把将来可能需要的属性预先放在实体类中，这样以后变动时，连实体类都不用变动。

二、实体类缺点在哪（仅是个人观点）？

虽然实体类有明显的优势，但亲身使用时会发现一个明显的问题：代码可读性貌似降低了。

上边例子中体现的不是很明显。再来一个简单的例子。

假如有一个方法(没有用实体类)：

selectByPartDate(DateTime startDate,DateTime endDate){}

此方法用来查询某段时间内的记录，两个参数：一个是起始时间，一个是结束时间。

虽然没有用实体类，可是让人看起来很舒服，一看就知道要干什么。

用了实体类后(假设实体类名是LoginLog)：

selectByPartDate(LoginLog startDate, LoginLog endDate){}

让人看了不知所措，难以理解到底想做什么。

当然，这种不知所措可以通过两个途径解决：

| 良好的命名规范，达到 “见名知意”。

| 良好的文档说明或者代码注释。

在这，引出一个问题：三层中，所有的方法都要用实体类传递参数吗？

最明显的就是上边selectByPartDate例子，还有诸如：deleteByID(longid){}这样的方法。真的有必要传递实体类吗？

实体类的确是容易扩展、修改，可这不违反设计原则吗？

设计原则是：尽量避免对原有代码的修改，而是通过增加代码的方式去解决。

诸如selectByPartDate、deleteByID这样的方法，目的已经很明确了：查询某段时间内的记录、根据id删除记录。换句话说，这就是它们存在的意义。

程序再怎么扩展，能涉及到这类方法？假如真的把这类方法扩展了，那么它们完全失去了自己的意义！

deleteByID就是根据id删除，扩展了，就不是根据id删除了！这时候你可以再添加一个新的方法，何必和deleteByID过不去呢？

对于参数极少，目的明确的方法，个人认为没必要用实体类。

这只是我的个人看法，欢迎高人指点！

三、源自实体类的灵感！

三层中，大家都知道U层的逻辑应该尽量少，尽可能的转移到B层。

但是实际应用中如何转移却是个问题。

就拿删除记录来说，U层调用B层，B层调用D层，由D层返回布尔值，来说明删除是否成功。

这样传递参数，最终U层得到的是一个布尔值，真或假，携带的信息太少了，只能反馈给用户成功或者失败(同时多了一次判断逻辑)，而为什么失败，就无从得知了。

现实应用中有很多这样的例子，有时候为了给出用户更详细的提示，不惜把B层分的很细，然后在界面大量的调用B层方法，加上大量的判断，才能给用户一个完整的提示。

这样的情形显然不是我们想要的？那么怎么解决呢？

造成这种情况的根本原因就是布尔型返回值携带的信息太少，哪个类型多？当然是字符串型！

在D层，可以返回布尔值，让B层判断使用。但是B层返回给U层的值，强烈反对是布尔型的！

按照这个思路，在B层使用复杂的逻辑，然后把执行结果以字符串的形式的返回。这样一来，U层无需任何判断，直接把B层返回的字符串显示出来就行了！

举个例子(B层的一个方法)：

[csharp] view plaincopyprint?

public string deleteMail(string domainName, Mail mail)
{
try
{
//删除POP3服务器中的邮箱
CMDHelper cmdHelper = new CMDHelper();
string cmdString = "";
cmdString = cmdHelper.execute("DEL " + mail.mailName + "@" + domainName + " /DELETEUSER");
if (cmdString.ToLower().IndexOf("successfully") >= 0) //删除成功
{
//同步数据库
IMailDAO mailDAO = creater.createMailDAO();
if (mailDAO.deleteByID(mail))
{
return "删除成功！数据库同步成功！";
}
else
{
return "删除成功！但数据库同步失败！";
}
}
else if (cmdString.IndexOf("系统找不到指定的文件") >= 0) //不存在
{
return "该邮箱不存在！";
}
else
{
return "未知原因错误！请联系管理员！";
}
}
catch (Exception ex)
{
throw ex;
}
}

很明显的看出，一切判断都是在B层完成的，然后把结果以字符串形式返回给U层，简洁明了，U层不需要任何逻辑，直接show就行了！

这样看上去很好，但是字符串还是比较让人不舒服，既然是面向对象，为何不返回一个实体类呢？

我们可以定义一个实体类，名字就叫LayerParameter。给这个实体类加一个字符串型的resultString属性，就把刚刚的字符串返回值封装进来了。就用这个实体类作为B层给U层的返回值。

这样做简直完美！

有经验的朋友可能遇到过刷新界面的问题，也就是U层需要根据实际情况来刷新界面数据，在B/S结构中尤其明显。有了实体类做返回值，就啥都不怕了！不就是刷新吗？在LayerParameter实体类中加一个布尔型属性refresh，U层调用B层后，show一下返回值(LayerParameter类实例)的resultString属性，把执行信息告诉用户，然后再判断一下refresh属性，决定是否刷新界面数据(U层一点逻辑都没有是不可能的！)，此时B层给U层的返回值，仍然是LayerParameter，接口无需任何改动。

以上仅仅是个人想法，希望大牛指点！

最后，申明一点：

一切的一切还是要以项目实践为基础，经验才是王道，否则一切讨论都是空穴来风！

浅谈三层架构中的实体类(C#)相关推荐

浅谈三层架构通过这个，+Java开发模式经验。终于相通了，动软到底是为什么这么做...
浅谈三层架构收藏自己理解的原理 http://www.cnblogs.com/mahaisong/archive/2011/05/12/2044665.html 浅谈三层架构通过这个,+Jav ...
浅谈三层架构、MVC之间的关系
什么是三层架构? 各个层的作用实体层的作用什么是MVC? 概念职能设计模式三层架构.MVC之间的关系关系示意图三层的优缺点 MVC的优缺点什么是三层架构? 三层架构(3-tier ar ...
浅谈“三层结构”原理与用意(转帖)
浅谈"三层结构"原理与用意序在刚刚步入"多层结构"Web应用程序开发的时候,我阅读过几篇关于"asp.net三层结构开发"的文章.但其多 ...
Java架构师成长之道之浅谈计算机系统架构
Java架构师成长之道之浅谈计算机系统架构 Java架构师成长之旅 1.1 信息技术发展趋势目前信息技术主要经历了互联网.移动互联网以及以大数据.云计算.人工智能和区块链为代表的新兴技术三个阶段.而 ...
【转】谈谈三层架构中MODEL的作用
Model又叫实体类,这个东西,大家可能觉得不好分层.包括我以前在内,是这样理解的:UI<-->Model<-->BLL<-->Model<-->DAL ...
Entity Framework在三层架构中的使用
本系列的前3篇文章已经向大家介绍了如何使用Entity Framework4(以下简称EF4)创建数据库并进行增删改查操作,还介绍了存储过程的调用方法.在以前的例子中,我们没对代码进行分层,只是简单的 ...
html 怪异模式,CSS_浅谈CSS编程中的怪异模式，怪异模式盒模型今天学习了 - phpStudy...
浅谈CSS编程中的怪异模式怪异模式盒模型今天学习了一下css3的box-sizing属性,顺便又温习了一下css的盒模型,最后觉得有必要对盒模型做一个全面整理. 先不考虑css3的情况,盒模型一共 ...
浅谈智能交通中的电子地图
浅谈智能交通中的电子地图 20世纪80年代以来,随着经济的发展和人口的增长,车和人的矛盾变得越来越尖锐,交通拥挤和阻塞现象日益严重,交通污染与交通事故等日益困扰着交通事业的发展.路网通过能力已不能满足 ...
mysql declare与set的区别_浅谈MySQL存储过程中declare和set定义变量的区别
在存储过程中常看到declare定义的变量和@set定义的变量.简单的来说,declare定义的类似是局部变量,@set定义的类似全局变量. 1.declare定义的变量类似java类中的局部变量,仅 ...

浅谈三层架构中的实体类(C#)

浅谈三层架构中的实体类(C#)相关推荐

最新文章

热门文章