【发布时间】：2013-05-28 18:15:44
【问题描述】：
我正在开发一个以 oracle 作为后端的 asp.net 项目。最初，我使用三层架构开发了这个应用程序，其中 UI 作为 aspx 页面，BLL 和 DAL 作为类库项目。我在 BLL 和 DAL 中都使用了静态类和方法。 DAL 仅由单个类组成，其静态方法为 Select、Execute 和 ExecuteScalar，它们接受 BLL 类转发的查询。
DAL
private static string connString = ""
private static OracleConnection conn;
public static OracleConnection OpenConn()
{
if (conn==null)
{
conn = new OracleConnection(connString);
}
if (conn.State != ConnectionState.Open)
{
conn.Open();
}
return conn;
}
public static DataTable Select(string query)
{
DataTable dt = new DataTable();
OracleDataAdapter da = new OracleDataAdapter(query, OpenConn());
da.Fill(dt);
return dt;
}
public static void Execute(string query)
{
OracleCommand cmd = new OracleCommand(query, OpenConn());
cmd.ExecuteNonQuery();
}
public static int ExecuteScaler(string query)
{
OracleCommand cmd = new OracleCommand(query, OpenConn());
int id = Convert.ToInt32(cmd.ExecuteScalar());
return id;
}
BLL 类调用这个 DAL 的方式如下 员工 BLL
public static DataTable GetEmployees(int facilityid)
{
DataTable dt = new DataTable();
string q = string.Format("SELECT * FROM ..");
dt = OraDAL.Select(q);
return dt;
}
public static DataTable AddEmployee(string name, , int departmentid , int employeeType)
{
DataTable dt = new DataTable();
string q = string.Format("INSERT INTO ...");
dt = OraDAL.Select(q);
return dt;
}
现在我正在重构应用程序。具有 BLL 和 DAL 的三层架构与类库项目相同，带有一个名为 Domain 的附加类库项目，以包含所有其他项目引用的域类。我使用这些类在层之间传输数据。这次将 DAL 类保持为静态，将 BLL 保持为普通类。我已将大部分功能（查询）移至 DAL。现在 DAL 拥有EmployeesDAL、DepartmentsDAL 等类以及包含Select、Execute 和ExecuteScalar 静态方法的泛型类。
Employee.cs
public class Employee
{
public int Id { get; set; }
public string Name { get; set; }
public Department department { get; set; }
public EmployeeType employeeType { get; set; }
}
员工DAL
public static List<Employee> GetEmployees(int departmentid)
{
if (departmentid > 0)
{
string query = string.Format("SELECT * FROM EMPLOYEES WHERE department='{0}')", departmentid);
return GetCollection(OraDAL.Select(query));
}
return null;
}
public static Employee GetEmployee(int employeeid)
{
if (employeeid > 0)
{
string query = string.Format("SELECT * FROM PMS_EMPLOYEES WHERE Id='{0}'", employeeid);
return GetSingle(OraDAL.Select(query));
}
throw new Exception("Employee id not valid");
}
public static int AddEmployee(Employee employee)
{
if (employee != null)
{
string query = string.Format("INSERT INTO PMS_EMPLOYEES (name, department, employee_type) VALUES ('{0}','{1}','{2}')", employee.Name, employee.department.Id, employee.employeeType.Id);
return OraDAL.Execute(query);
}
throw new Exception("Values not valid");
}
private static List<Employee> GetCollection(DataTable table)
{
List<Employee> employees = null;
if (table != null)
{
if (table.Rows.Count > 0)
{
employees = new List<Employee>();
foreach (DataRow row in table.Rows)
{
employees.Add(ReadDataRow(row));
}
}
}
return employees;
}
private static Employee GetSingle(DataTable table)
{
if (table != null)
{
if (table.Rows.Count > 0)
{
DataRow row = table.Rows[0];
return ReadDataRow(row);
}
}
return null;
}
private static Employee ReadDataRow(DataRow row)
{
Employee employee = new Employee()
{
Id=int.Parse(row["ID"].ToString()),
Name=row["NAME"].ToString(),
employeeType=EmployeeTypesDAL.GetEmployeeType(int.Parse(row["EMPLOYEE_TYPE"].ToString())),
department=DepartmentsDAL.GetDepartment(int.Parse(row["DEPARTMENT"].ToString()))
};
return employee;
}
EmployeesBLL.cs
public class EmployeesBLL
{
public List<Employee> GetEmployees(int departmentid)
{
if (departmentid > 0)
{
return EmployeesDAL.GetEmployees(departmentid);
}
return null;
}
public int AddEmployee(Employee employee)
{
if (employee != null)
{
return EmployeesDAL.AddEmployee(employee);
}
throw new Exception("Employee cannot be null");
}
帖子越来越长，但我希望您能更好地了解情况。 我在新设计中遇到了一些问题，让我问了这个问题，这是做事的正确方法吗？因为主要目标是避免在不同层之间来回移动数据表。虽然这种新的逻辑编码方式太费时，但值得付出努力。业务层变得太薄了，因为他们提供的唯一服务似乎是从 DAL 调用类似的方法，我首先需要 BLL 吗？如果是的话，什么情况下可能需要单独的 BLL。
编辑
我注意到上述设计的一个问题是数据库调用的数量。调用太多，因为当一个对象被填充时，所有子对象也被填充，导致对数据库的调用。例如填充 Employee 对象将导致填充部门实例。在大多数情况下，我只需要部门 ID 而不是整个部门的信息。
【问题讨论】：
-
你的设计是数据驱动设计的一个很好的例子，是的——在它里面，业务逻辑只是对 crud 操作的包装。这真的很好，如果你的应用程序只做粗加工。顺便说一句，如果您打算让 BL 承担更多责任，请考虑 O/RM 方法，否则您将花费太多时间来支持您的数据访问层代码库。
标签： c# asp.net architecture n-tier-architecture