【问题标题】:LINQ to SQL in 3-layer architecture三层架构中的 LINQ to SQL
【发布时间】:2010-11-04 05:31:25
【问题描述】:

我目前使用 3 层架构(DAL、BLL、表示层)。

我想知道如何使用 LINQ to SQL 实现 3 层架构。我不知道 LINQ 应该在 DAL 还是 BLL 中。 LiNQ 似乎是 DAL 和 BLL 的融合。

以前有人在 3 层架构中实现过 LINQ 吗?

【问题讨论】:

    标签: linq-to-sql


    【解决方案1】:

    我使用 Linq-to-SQL/XML,我认为我的应用程序是 3 层。与 pre-Linq 应用程序的区别在于,现在数据访问层更小更轻,这实际上是一件非常好的事情!

    在我的旧 DAL 中,我会有如下方法:

    public virtual int CountCustomersInCountry(string country) {
        // Plug in raw SQL.
    }
    
    public virtual List<Customer> GetCustomersInCountry(string country) {
        // Plug in raw SQL.
    }
    
    public virtual int CountCustomersForDepartment(string department) {
        // Plug in raw SQL.
    }
    
    public virtual List<Customer> GetCustomersForDepartment(string department) {
        // Plug in raw SQL.
    }
    
    etc. etc. ad-infinitum
    

    我现在有以下几种方法:

    public virtual int Count(Expression<Func<T, bool>> where) {
        // Plug in Linq-to-SQL DataContext here.        
    }
    
    public virtual T Get(Expression<Func<T, bool>> where) {
         // Plug in Linq-to-SQL DataContext here.   
    }
    
    public virtual List<T> Get(Expression<Func<T, bool>> where,  string orderByField, int offset, int count) {
        // Plug in Linq-to-SQL DataContext here.   
    }
    

    要调用新的 DAL 方法并在 DynamicLinq 的帮助下使用:

    int countryCount = Count(c => c.Country == country);
    List<Customer> customers = Get(c => c.Country == country, "inserted", 0, 25);
    int departmentCount = Count(c => c.Department == department);
    List<Customer> customers = Get(c => c.Department == department, "inserted", 0, 25);
    

    在您开始使用 Linq2SQL 进行单行调用的添加、更新和删除之前,所有这一切!我的 DAL 现在包含 10 种方法,而以前很容易为我的 DAL 所照顾的每个对象获得多达 20 到 30 种方法!我强烈建议您尝试一下,因为它确实可以为您节省大量代码。

    【讨论】:

    • 那是史诗般的......我正在研究基于提供者模型的索赔处理应用程序的实现......如果我在编写 CoreClaimsProvider 类时知道这一点......那些 200 多种方法太少了……天才!!!
    【解决方案2】:

    LINQ-to-SQL 主要是关于 DAL - 它是一种数据访问技术。但是,在一个足够简单的应用程序中,没有什么能阻止您将 LINQ 创建的对象传递到业务层,甚至将它们绑定到您的 UI。为什么不呢?

    但是,您需要注意,在这种情况下,您将自己与 LINQ-to-SQL 紧密联系在一起。如果这对您的场景没问题 - 太好了,使用它!这是您需要根据项目需求为自己做出的设计决策。

    如果系统变得更复杂,特别是如果您从数据库表创建的 LINQ 对象与您的业务对象不匹配 1:1,您总是可以使用业务层从您的 LINQ 对象“组装”真实的业务对象.借助AutoMapper 之类的工具,您甚至可以编写大量左右分配“猴子”代码:-)

    另一方面,如果您处于这种情况,您可能还想查看 ADO.NET Entity Framework 而不是 LINQ-to-SQL。 EF 为您提供了许多这些更高级的功能,这些功能对于小型应用程序来说可能是多余的,但对于企业应用程序来说可能绝对是至关重要的。诸如支持多个数据库供应商之类的事情,诸如将您的业务对象映射到数据库中的不同物理表示等等之类的事情。

    马克

    【讨论】:

      【解决方案3】:

      LiNQ 创建的对象通常被描述为业务层对象,尽管它们与数据层的耦合确实比通常建议的要高。但是,如果您的结构比 LiNQ 中直接表示的结构更高,那么额外的控制器可以将其作为业务层进行操作,而 LiNQ 则更像是数据层。

      这实际上取决于数据库中表示的对象的范围,以及您希望达到的耦合程度。由于 LiNQ 将重点放在可查询对象上,因此它可能会过度渗透到应用程序中。

      【讨论】:

        【解决方案4】:

        我认为这取决于您如何看待使用 LINQ。在正常的计划中,我认为它确实位于 DAL 中,因为它紧密遵循底层数据结构。然后,您可以在 BLL 中对其进行抽象。

        【讨论】:

          【解决方案5】:

          LINQ 不适合 3 层架构。它最适合 2 层架构。

          我个人在 3 层中完成我的学位项目并决定使用 LINQ,但后来由于许多问题我放弃了这个想法。最大的问题是“乐观并发控制”

          因为 LINQ 的实体对象在 DataContext 的连接环境中工作。所以在更新和删除逻辑期间。它给出了错误。

          【讨论】:

          • 您可能没有正确使用 DataContext。应该为每个“单个工作单元”msdn.microsoft.com/en-us/library/… 创建它们。如果您在不同的操作中遇到错误,我怀疑您正在尝试将相同的 DataContext 对象用于不止一件事。
          【解决方案6】:

          我在 DAL 项目中添加实体并为我需要的访问权限创建一个存储库。如果您真的不想在 BLL 中使用 Linq to SQL 对象,则需要使用双重映射技术。使用存储库模式可以轻松模拟 DAL。

          【讨论】:

            【解决方案7】:

            我用 linq 和 3 层写了一个简单的电话簿,你可以下载它,如果你对这个填充有任何疑问,请随时问我。

            可在:http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=7597&lngWId=10

            【讨论】:

              猜你喜欢
              • 2010-10-24
              • 1970-01-01
              • 2011-10-02
              • 1970-01-01
              • 1970-01-01
              • 2013-11-16
              • 2016-05-19
              • 1970-01-01
              • 1970-01-01
              相关资源
              最近更新 更多