数据访问层 - LINQ-To-SQL 和泛型。我可以优化这个吗？

Posted 2023-02-24

【中文标题】数据访问层 - LINQ-To-SQL 和泛型。我可以优化这个吗？

【英文标题】：Data Access Layer - LINQ-To-SQL and generics. Can I optimize this?

【发布时间】：2011-03-30 10:39:54

【问题描述】：

我们正在努力改进我们的 DAL，它是用 LINQ 编写的，可以与 MS SQL 数据库对话。我们的目标是用尽可能少的代码实现良好的可重用性。

LINQ 生成的文件使用泛型和反射将 LINQ 生成的类映射到 SQL 对象（在我们的例子中是表和视图）。

请查看现有访问器的示例。此方法驻留在包含自定义构造函数、访问器和修改器的部分类中：

public clsDVD getDVD(int dvdId)

   try
   
      using (DataContext dvdDC = new DataContext(ConnectionStringManager.getLiveConnStr()))
      
                    // Deferred loading
                    dvdDC.DeferredLoadingEnabled = false;

                    var tDVD = dvdDC.GetTable<DVD>();

                    return (from t in tDVD 
                            // Filter on DVD Id
                            where t.DVDId == (dvdId)
                            select t).Single();                   
      
   catch (Exception e)
   
       Logger.Log("Can't get requested DVD.", e);
       throw;
   
 

我相信这很容易维护，因为大部分工作都是在var tDVD之后完成的

建议不要声明tDVD，而是使用dataContext.TableName，但在幕后它仍然调用GetTable<>。

我能看到的唯一改进方法是将这个部分类分解为 4 个 (CRUD) 部分类。例如

clsDVD_Select, clsDVD_Update, clsDVD_Insert, clsDVD_Delete

在这种情况下，每个类将代表一组行为。

我们正在讨论的想法是看看是否可以在 LINQ 泛型之上使用泛型。

例如，我们将通过对 SQL 数据库使用反射来随时找出类的属性，而不是使用部分类。我首先关心的是性能影响。会有多大意义。

我们将使用以下内容代替ClsDVD.getDVD(1231)：GenericDC.Select<DVD>(1231)

.Select 方法将找出主键并在该表上运行选择查询。我很难理解这是如何工作的。假设我们可以让它适用于简单的选择，即在主键上使用过滤器进行选择，但是当我们开始执行复杂的连接和按选择分组时会发生什么。当我们希望每个 DVD 类有多个选择时会发生什么？

我最后关心的是良好做法。之前有人告诉我，拥有一致的代码是件好事。例如，如果我决定使用数据表，那么我应该在整个项目中坚持使用数据表。让项目的一半使用数据表而另一半使用用户定义的类是一个坏主意。你同意吗？

我认为现有的实现非常好，但也许我错过了一些非常明显的东西，并且有一种更简单、更面向对象的方法来实现相同的结果？

谢谢

【问题讨论】：

您说，“LINQ 生成的文件使用泛型和反射将 LINQ 生成的类映射到 SQL 对象（在我们的例子中是表和视图）。”为什么您的 LINQ 生成的类没有已经代表您的 SQL 对象（表/视图）？为什么要为此设置两个单独的类？

您好，LINQ 生成的类位于 .dbml 文件中，它们直接映射到 SQL 对象，我确实使用了它们。例如 LINQ 为 DVD 生成一个类。我添加了一个也称为 DVD 的部分类，它具有我的访问器方法 - getDVD。

我确实需要将 CRUD 方法存储在某处，但我不能将它们与 LINQ 生成的代码一起存储，因为当我添加/删除/修改 SQL 对象时它会被大量修改。部分类只是让它更整洁

你的意思是 Linq2SQL 而不仅仅是“LINQ”吗？

是的，我会更新标题。谢谢

【参考方案1】：

这是使这种情况更通用的一种方法。 Rince 并重复其他 CRUD 操作。对于某些情况，性能可能是不可接受的。在这些情况下，我会重组程序的那一部分以调用非通用版本。

public T GetSingleItem(Func<T,bool> idSelector ) where T : ??? // forgot what type it needs to be off the top of my head
 
    try 
     
        using (DataContext context = new DataContext(ConnectionStringManager.getLiveConnStr())) 
         
            context.DeferredLoadingEnabled = false; 
            return context.GetTable<T>().Single( item => idSelector( item );
         
    
    catch (Exception e) 
     
        Logger.Log("Can't get requested item.", e); 
        throw; 
     
 

这将是您获得该物品的方式。不太优雅，因为您必须告诉通用函数您将使用哪一列。

GenericDC.GetSingleItem<DVD>( dvd => dvd.ID == 1231 )

为了使其更加通用，而不是将其限制为具有 ID 的单个项目...

public IEnumerable<T> GetItems(Func<T,bool> selectFunction ) where T : ??? // forgot what type it needs to be off the top of my head
 
    try 
     
        using (DataContext context = new DataContext(ConnectionStringManager.getLiveConnStr())) 
         
            context.DeferredLoadingEnabled = false; 
            return context.GetTable<T>().Select( item => selectFunction( item );
         
    
    catch (Exception e) 
     
        Logger.Log("Can't get requested item.", e); 
        throw; 
     
 

那么你可以这样称呼它：

GenericDC.GetItems<DVD>( dvd => dvd.Title == "Title" && dvd.Cast.Contains( "Actor" ) );

另一种可能的解决方案是创建一个自定义代码生成器，您可以在一个地方进行修改，并为所有其他类型创建类似的例程。如果您遇到性能问题，这可能是一个很好的解决方案。您可能希望限制对您使用的模板代码段的更改。

【讨论】：

嘿，您示例中的代码非常合理。我担心的是我并不总是需要 idSelector，我可能会有很少连接和 group by 子句的选择器。参考您所说的自定义代码生成器。这真的会提高代码的维护性和可重用性吗？

getDVD 或 getSingleItem 工作正常。回到 DVD 示例，我可能希望通过以下任何标准来选择 DVD：演员、流派、评级等。目前，实现这一点的唯一方法（我能看到的）是添加额外的方法或创建一个 DVDSelect 类，然后向下继承到 DVDSelect_Rating、DVDSelect_Title 等。

如果您想按任何列进行选择，那么您可以将代码调整为“选择器”，这样您就可以查看所需的任何列和多少列。在那种情况下，它可能不会是“单一”操作。就加入而言，这使事情变得更加复杂。我还没有找到一个好的通用方法来做到这一点。

我发现代码生成器有好有坏。当它们没有跟上并且有人修改了输出的源时，它们就会变坏。

如果要在多个地方使用选择器，我肯定会提取该逻辑。 IMO，重复代码是要消除的第一件事。在此示例中，您可能有一个“DvdFinder”类，其中包含“ById”、“ByTitle”、“ByActor”等方法。VISITOR 模式可能会在您需要多个标准的情况下帮助您。同样，join 和 group by 将是您实施中最困难的部分。最简单的方法可能是在没有泛型开始的情况下一个接一个地创建函数。然后寻找共性。