例如,如果您有一个名为Person(ID,Name等)的数据库表,那么数据访问层应该返回业务层的对象是什么类型的? 我在想这样的事情:
//data access tier
public class DataAccess{
public interface IPerson{
int ID{ get; set; }
string Name{ get; set; }
}
internal class Person : IPerson{
private int id;
private string name;
public int ID{ get{return id; } set{ id=value; } }
public int Name{ get{retutn name; } set{ name=value; }
}
public static IPerson GetPerson(int personId)
{
//get person record from db, populate Person object
return person;
}
}
//business tier
public class Person : IPerson{
private int id;
private string name;
public int ID{ get{return id;} set{id=value;} }
public string Name{ get{return name;} set{name=value;} }
public void Populate(int personId){
IPerson temp = DataAccess.GetPerson(personId);
this.ID = temp.ID;
this.Name = temp.Name;
}
}
但这一切看起来有点麻烦?这个问题有更优雅的解决方案吗?我应该将DataRow从数据访问层返回到业务层吗?
答案 0 :(得分:21)
您无需在数据访问层(DAL)中重复类定义。
您可以在单独的程序集中将您的业务实体创建为“哑”容器,例如你的Person类可以是: -
public class Person
{
int ID { get; set: }
string Name { get; set: }
}
然后,您可以为DAL提供对业务实体层的引用。您的控制器对象,无论它们是在单独的业务逻辑层中,还是在您的UI层中,都可以调用DAL,DAL可以创建业务实体,从数据库填充它并将其返回给您的控制器。
Imar Spaanjaars的This article对这种模式有一个很好的解释。
答案 1 :(得分:5)
您的业务层肯定不想了解数据行 - 尝试在数据层中保留特定于数据的类。这减少了耦合并使您可以在以后更改持久层,而无需进行批量重新构建。
要解决您的具体问题,您可以:
你可能想要考虑的另一件事是层层次 - 这对你如何看待这些事情有所不同。层通常是物理的,换句话说,它们定义了流程之间的界限。图层通常是合乎逻辑的,它们将程序的功能分成松散耦合的单元。在这种情况下,你的目标是分层。
答案 2 :(得分:1)
如果您创建DAO类的接口并将它们放在业务层中,则可以从数据访问层引用业务层。数据层中的DAO类从业务层返回对象。
您的业务层引用接口而不是直接引用数据访问对象。通过IoC容器(例如Castle Windsor)进行依赖注入将允许您完成此操作。
此技术称为分离接口,在此处描述:
http://www.martinfowler.com/eaaCatalog/separatedInterface.html
我所看到的这种技术的最佳解释可以在这篇关于NHibernate最佳实践的文章中找到,由Billy McCafferty撰写。
http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx
这篇文章有很多特定于NHiberbate的信息,但其中很大一部分只是关于设计松散耦合和易于单元测试的应用程序的可靠信息。
答案 3 :(得分:0)
由于此规则要求每个层都必须松散耦合到上层,因此向DAL添加BL引用并不是一个好主意。 它更好地在DAL中使用接口定义数据模型,并在BL中创建Business Entity表单。 根据我的经验,最好在DAL中使用Repository并在您的业务实体或业务流程中访问。