现在LINQ
toSQL
稍微成熟了一点,我想知道人们使用该技术创建n 层解决方案的任何技术,因为这对我来说似乎并不那么明显。
7 回答
嗯,Rockford Lhotka很难过,LINQ to SQL 是从数据库中获取数据的绝妙技术。他建议,之后它们必须绑定到“到达域对象”(又名 CSLA 对象)。
严肃地说,LINQ to SQL 支持 n 层架构,请参阅DataContext.Update方法。
您可能希望将ADO .Net Entity Framework作为 LINQ to SQL 的替代方案,尽管它也支持 LINQ。我相信 LINQ to SQL 被设计为相当轻量级和简单,而实体框架更重,可能更适合大型企业应用程序。
LINQ to SQL 并没有我见过的真正的 n 层故事,因为它创建的对象是在类中创建的,其余部分是在类中创建的,因此您实际上没有可以很好地引用的程序集诸如网络服务之类的东西。
我真正考虑的唯一方法是使用 datacontext 来获取数据,然后填充中间数据模型,将其传递并在两侧引用它,然后在客户端使用它 - 然后将它们传回并推送数据返回到新的 Datacontext 或在重新获取行后智能更新行。
那就是如果我了解您要了解的内容:\
当我第一次开始查看它时,我在他的博客上向 ScottGu 提出了同样的问题 - 但我还没有看到一个以这种方式使用 LINQ to SQL 的场景或应用程序。像 Rob Connery 的 Storefront 这样的网站离供应商更近。
好的,我将给自己一个可能的解决方案。
插入/更新从来都不是问题;您可以将业务逻辑包装在 Save/Update 方法中;例如
public class EmployeesDAL
{
...
SaveEmployee(Employee employee)
{
//data formatting
employee.FirstName = employee.FirstName.Trim();
employee.LastName = employee.LastName.Trim();
//business rules
if(employee.FirstName.Length > 0 && employee.LastName.Length > 0)
{
MyCompanyContext context = new MyCompanyContext();
//insert
if(employee.empid == 0)
context.Employees.InsertOnSubmit(employee);
else
{
//update goes here
}
context.SubmitChanges();
}
else
throw new BusinessRuleException("Employees must have first and last names");
}
}
对于获取数据,或者至少获取来自多个表的数据,您可以使用存储过程或视图,因为结果不会是匿名的,因此您可以从外部方法返回它们。例如,使用存储过程:
public ISingleResult<GetEmployeesAndManagersResult> LoadEmployeesAndManagers()
{
MyCompanyContext context = new MyCompanyContext();
var emps = context.GetEmployeesAndManagers();
return emps;
}
严肃地说,LINQ to SQL 支持 n 层架构,请参阅 DataContext.Update 方法
我读过的一些内容表明业务逻辑包装了 DataContext - 换句话说,您以您建议的方式包装更新。
我传统上编写业务对象的方式通常也将“加载方法”封装在 BO 中;所以我可能有一个名为 LoadEmployeesAndManagers 的方法,它返回员工及其直属经理的列表(这是一个人为的例子)。也许它只是我,但在我的前端,我宁愿看到 e.LoadEmployeesAndManagers() 而不是一些长的 LINQ 语句。
无论如何,使用 LINQ 它可能看起来像这样(未检查语法正确性):
var emps = from e in Employees
join m in Employees
on e.ManagerEmpID equals m.EmpID
select new
{ e,
m.FullName
};
现在,如果我理解正确,如果我把它放在一个类库中并从我的前端调用它,我可以返回它的唯一方法是作为一个 IEnumerable,所以我失去了强类型的优点。我能够返回强类型对象的唯一方法是创建自己的Employees 类(加上一个字符串字段作为经理姓名)并从我的LINQ to SQL 语句的结果中填充它,然后返回它。但这似乎违反直觉......如果我必须做所有这些,LINQ to SQL 到底给我买了什么?
我认为我可能以错误的方式看待事物;任何启示将不胜感激。
“我可以返回它的唯一方法是作为 IEnumerable,所以我失去了强类型的优点”
这是不正确的。事实上,您的查询是强类型的,它只是一种匿名类型。我认为您想要的查询更像是:
var emps = from e in Employees
join m in Employees
on e.ManagerEmpID equals m.EmpID
select new Employee
{ e,
m.FullName
};
这将返回 IEnumerable。
这是我写的一篇关于这个主题的文章。
Linq-to-sql 是一个 ORM。它不会影响您设计 N 层应用程序的方式。您使用它的方式与使用任何其他 ORM 的方式相同。
@liammclennan
这将返回 IEnumerable。... Linq-to-sql 是一个 ORM。它不会影响您设计 N 层应用程序的方式。您使用它的方式与使用任何其他 ORM 的方式相同。
那我想我还是一头雾水。是的,Linq-to-Sql 是一个 ORM;但据我所知,我仍在用内联 sql 类型语句(linq,而不是 sql ......但我仍然觉得这应该从前端抽象出来)乱扔我的前端代码。
假设我将我们一直用作示例的 LINQ 语句包装在一个方法中。据我所知,我可以返回它的唯一方法是:
public class EmployeesDAL
{
public IEnumerable LoadEmployeesAndManagers()
{
MyCompanyContext context = new MyCompanyContext();
var emps = from e in context.Employees
join m in context.Employees
on e.ManagerEmpID equals m.EmpID
select new
{ e,
m.FullName
};
return emps;
}
}
从我的前端代码我会做这样的事情:
EmployeesDAL dal = new EmployeesDAL;
var emps = dal.LoadEmployeesAndManagers();
这当然会返回一个 IEnumerable;但我不能像你说的任何其他 ORM 一样使用它(除非我当然误解了),因为我不能这样做(再次,这是一个人为的例子):
txtEmployeeName.Text = emps[0].FullName
这就是我所说的“我失去了强类型的优点”。我想我开始同意坩埚了。LINQ-to-SQL 并非旨在以这种方式使用。再说一次,如果我看东西不正确,有人给我指路:)