logo标签列表

如何在N层解决方案中使用LINQ To SQL？

linq-to-sqln-tier-architecture
15

现在 LINQ to SQL 已经比较成熟了，我想知道人们使用什么技术来创建一个基于该技术的n层解决方案，因为这对我来说并不那么明显。

7个回答
1

好的，我打算给自己提供一个可能的解决方案。

插入/更新从来都不是问题；你可以将业务逻辑封装在一个保存/更新方法中；例如：

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;
    }
1

哦，Rockford Lhotka说，LINQ to SQL是从数据库获取数据的绝妙技术。他建议之后必须将其绑定到“可达领域对象”（又名CSLA对象）。

严肃地说，LINQ to SQL对于n层架构有支持，可以看到DataContext.Update方法。

1

你可能想要研究一下ADO .Net Entity Framework，作为 LINQ to SQL 的替代方案，虽然它也支持 LINQ。我认为 LINQ to SQL 被设计成相当轻量级和简单，而 Entity Framework 更加重型，可能更适合大型企业应用程序。

1

LINQ to SQL实际上没有我见过的n层业务架构，因为它创建的对象是在类中创建的，您没有一个可以通过诸如Web服务等方式很好引用的程序集。

我唯一真正考虑它的方式是使用数据上下文来获取数据，然后填充一个中间数据模型，通过该模型进行传递，并在两侧引用它，在客户端使用它 - 然后将它们传回并将数据推回到新的Datacontext或在重新获取它们后智能地更新行。

这是如果我理解你试图达到什么目的的话：\

当我第一次开始研究时，我在ScottGu的博客上问了相同的问题-但我没有看到任何一个场景或应用程序在野外使用LINQ to SQL。

Rob Connery的商店之类的网站更接近提供者。

0
说实话，LINQ to SQL 支持 n-tier 架构，可以使用 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究竟为我带来了什么好处，如果我必须这样做呢？
我认为我可能是从错误的角度看待事情的；任何启示都将不胜感激。
0
“我唯一能返回这个的方式是作为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一样使用它。

0

@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

这就是我所说的“我失去了强类型好处”的意思。我认为我开始同意 Crucible 的观点了；LINQ-to-SQL 并不是设计用于这种方式的。如果我看错了什么，请有人指引我 :)

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接