【问题标题】:Problem with LINQ in asp.netasp.net中的LINQ问题
【发布时间】:2010-01-11 11:18:42
【问题描述】:

我想在 ASP.NET 中实现 LINQ 以从数据表中过滤所需的数据。我怀疑什么是正确的地方。我有以下选择

  1. 在表示层 *.aspx.cs
  2. 在我们的业务层。
  3. 在我们的数据库层,对数据库的查询会作为数据表返回给业务层。业务层然后将结果返回给表示层。

谁能帮我找到适合 LINQ 的位置,因为现在我必须根据用户选择器过滤器进一步过滤数据表中的数据。

请帮忙?

【问题讨论】:

    标签: asp.net linq datatable


    【解决方案1】:

    Linq 可用于所有层,但进行此类操作的最佳位置是在业务层中。 这将使代码更易于维护和共享,以供将来在其他页面中使用。

    【讨论】:

      【解决方案2】:

      如果您只是使用 linq 过滤数据(例如 linq 到对象,linq 到数据集) - 您可以在业务层中使用它。

      如果您正在执行 linq to sql 并进行数据操作,那么您可以使用它的数据访问层。但是如果它太小了,那么你可以在任何你想要的层中使用它。

      【讨论】:

        【解决方案3】:

        为什么不试试 ASP .NET MVC 框架呢?它建立在 ASP .NET 之上(因此您可以从它的所有功能中受益),而且您拥有适当的层以及相当好的关注点分离。正如其他人回答的那样,理论上最好的选择是将代码放在业务层中。那是 ASP .NET MVC 结构的模型部分。

        试一试,你的答案自然会出现。

        【讨论】:

          【解决方案4】:

          Hemant,我认为您的关键陈述是“我必须进一步根据用户选择器过滤器从数据表中过滤数据。”最初的数据选择显然应该来自您的业务层,以 A) 将数据库与 UI 隔离,并且 B) 实施任何特定于业务的规则,以在将数据传递到 UI 之前“调节”数据。

          鉴于您只是根据用户交互选择子集,我认为将逻辑放在 UI 中是完全合理的。事实上,这可能是唯一在 UI 中执行以数据为中心的操作有意义的条件。

          话虽如此,我已经在业务逻辑层的一个专门类中实现了基于用户的过滤。这对我来说是合理的,因为所有用户过滤都有一个非常具体的关注点(它不涉及整个数据库)。

          所以 - 这是您的选择。如果您确实只是实现了用户过滤器,并且不同的页面根据它们显示的数据具有不同类型的过滤器,那么您有一个合理的论据将过滤逻辑(仅)放置在 UI 层中。毕竟,您,正在实现 UI 交互代码!但是,如果有一种简洁的方法可以将允许您的用户请求的过滤器范围封装在一个所有页面都使用的单独类中,那么我建议将该类放在您的业务逻辑层中。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2013-01-11
            • 1970-01-01
            • 1970-01-01
            • 2010-11-27
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多