假设我在SQL DB中有'Customer'表,而我正在使用Entity Framework。
现在,例如,在Controller或ViewModel中,我按var customer = Page.Current.Customer
检索客户的代码是:
public class Page
{
...
// Customer is EntityObject that created by Entity Framework
public Customer Customer
{
get
{
return (new ContextEntity()).Customers.First();
}
}
}
我的问题:
我应该将实体对象类(Customer)称为DAL并创建CustomerWrapper,还是可以在我的应用程序的其他代码中使用它?
我的意思是,Page.Current.Customer
将返回客户实体是否正确,或者我应该使用客户实体作为DAL和Page.Current.Customer应该返回自定义客户,某种CustomWrapper?
一方面如果决定将Customer表名更改为 site_Customer (在SQL DB中),我将刷新EntityModel并仅将Page类中的代码更改为
public class Page
{
...
// Customer is EntityObject that created by Entity Framework
public Customer Customer
{
get
{
return (new ContextEntity()).site_Customers.First();
}
}
}
但另一方面,我将拥有Customer Entity + WrapperCustomer
什么更好?
答案 0 :(得分:1)
EDMX文件中的所有类都是分部类。这意味着您可以通过创建新的类文件来扩展这些类。
例如......
public partial class Customer
{
// Here are the methods, properties, relationships created by EDMX Wizard.
}
在项目的另一个区域,我通常把它放在与EDMX相同的位置,你可以添加一个具有相同签名的新类文件。
public partial class Customer
{
// Here are the methods, properties, etc. created by you.
}
编译项目时,这两个类将成为编译代码中的一个类。现在,当您更改EDMX时,是的它应该正确映射,但情况并非总是如此,因为已知EF非常错误(假设在MVC 3中使用EF 4.1修复),您只需更改类名匹配EDMX中的任何内容和“Voila!”您已将该类的所有自定义添加代码传输到新实体对象。这基本上是你的“类包装器”。
答案 1 :(得分:0)
这一切都取决于您希望在应用程序中使用的抽象级别以及表示层的需求。两种方法都是可能的。
您的代码可能已经与实体框架紧密耦合(EntityObject
是EF类型)并且它也不是很可测试(Page.Current
可能是静态的)所以讨论一些更高级的架构方法和不需要分离关注点。
您的代码中很少有观察结果:
答案 2 :(得分:0)
如果您想使用WCF,那么您可能需要创建清晰的POCO以避免很多问题。
如果您希望您的controllers / viewmodels / pages /无论是单元可测试的,那么您需要在存储库接口+类中抽象您的EntityContext(参见repository pattern)。
如果您只想制作一个快速简单的不可测试的应用程序,那么您不需要为此烦恼。不要忘记在每个请求结束时处理数据上下文。