實體類是現實實體在計算機中的表示。比如一個人就是一個實體。當然，你也可以認爲一扒屎是一個實體。我沒意見的。
它貫穿於整個架構，負擔着在各層次及模塊間傳遞數據的職責。大多情況下，實體類和數據庫中的表（這裏指實體表，不包括表示多對多對應的關係表）是一一對應的，但這並不是一個限制。
比如我們的數據庫中有個表User。我們就可以在項目中創建User的實體類，這個類的一個實例化對象就表示一個User。
上一篇博文提到的各層返回值的規範問題，就可以利用返回一個實體(或者實體的泛型集合)來實現。如果返回的實體有問題，就會在編譯的時候給出錯誤提示。
實體類存放在Model或者Entity層中，那倆單詞都表示實體。這裏我們使用Model。
新建一個項目，命名爲Model，並新建一個類，類名爲UserInfo.cs。
這裏我們再複習一下表User的字段。
將這些字段全部作爲UserInfo實體類的屬性。
UserInfo的內容如下:
using System;
namespace Model
{
/// <summary>
/// 表示用戶信息的實體類
/// </summary>
public class UserInfo
{
private int userId;
private string password;
private bool isAdmin;
private string userName;
private bool sex;
private Int16 age;
/// <summary>
/// 默認的構造函數
/// </summary>
public UserInfo() { }
/// <summary>
/// 帶參的構造函數
/// </summary>
/// <param name="userId">用戶Id</param>
/// <param name="password">用戶密碼</param>
/// <param name="isAdmin">是否爲管理員</param>
/// <param name="userName">用戶名</param>
/// <param name="sex">用戶性別</param>
/// <param name="age">用戶年齡</param>
public UserInfo(int userId, string password, bool isAdmin, string userName, bool sex, Int16 age)
{
this.userId = userId;
this.password = password;
this.isAdmin = isAdmin;
this.userName = userName;
this.sex = sex;
this.age = age;
}
public int UserId
{
get { return userId; }
set { userId = value; }
}
public string Password
{
get { return password; }
set { password = value; }
}
public bool IsAdmin
{
get { return isAdmin; }
set { isAdmin = value; }
}
public string UserName
{
get { return userName; }
set { userName = value; }
}
public bool Sex
{
get { return sex; }
set { sex = value; }
}
public Int16 Age
{
get { return age; }
set { age = value; }
}
}
}
DAL中的User.cs:
using System.Data;
using System.Data.SqlClient;
using DBUtility;
using Model;
namespace DAL
{
public class User
{
private const string SQL_SELECT_USERINFO_BY_USERID = "SELECT * FROM [User] WHERE UserId = @UserId";
private const string PARM_USERID = "@UserId";
/// <summary>
/// 根據用戶Id獲取用戶信息
/// </summary>
/// <param name="userId">用戶Id</param>
/// <returns>用戶信息</returns>
public UserInfo GetUserInfo(string userId)
{
UserInfo user = null;
SqlParameter parm = new SqlParameter(PARM_USERID, SqlDbType.VarChar, 10);//參數UserId
parm.Value = userId;//給參數賦值
using (SqlDataReader rdr = SqlHelper.ExecuteReader(SqlHelper.ConnectionStringLocalTransaction, CommandType.Text, SQL_SELECT_USERINFO_BY_USERID, parm))
{
if (rdr.Read())
{
user = new UserInfo(rdr.GetInt32(0), rdr.GetString(1), rdr.GetBoolean(2), rdr.GetString(3), rdr.GetBoolean(4), rdr.GetInt16(5));
}
else user = new UserInfo();
}
return user;
}
}
}
BLL中的User.cs:
namespace BLL
{
public class User
{
DAL.User user = new DAL.User();
/// <summary>
/// 根據用戶Id獲取用戶密碼
/// </summary>
/// <param name="userId">用戶Id</param>
/// <returns>用戶密碼</returns>
public string GetUserPassword(string userId)
{
return user.GetUserInfo(userId).Password;
}
/// <summary>
/// 根據用戶Id獲取用戶姓名
/// </summary>
/// <param name="userId">用戶Id</param>
/// <returns>用戶姓名</returns>
public string GetUserName(string userId)
{
return user.GetUserInfo(userId).UserName;
}
}
}
可見，DAL中的User.cs只剩下一個方法。返回值是UserInfo類型的。這樣就保證了層與層之間數據的傳輸規範。
到目前爲止，三層結構基本上是建好了。還有什麼欠缺的麼。如果有一天，Boss覺得SQL Server不爽，想用Oracle或者是MySQL或者是Access的時候怎麼辦呢。更換數據庫可不是小事喲，會叫人精盡而亡的。
有沒有辦法對這種情況進行預防呢。
具體怎麼做請看下一篇博文:ASP.NET三層結構演化構建之五——啥都能用。