问题标签 [business-logic-layer]

我以前从未使用过实体框架，我想尝试一些个人项目来实现它以使我的脚湿透。

我看到实体可以暴露给表示层。但我不希望暴露某些字段，例如修改日期和创建日期等字段以及各种其他数据库字段。

我如何实现业务对象并只公开我需要的属性但仍保持对象可序列化？

还有这比 LinqToSql 有什么优势？

我们正在构建一个包含许多层的大型 Web 应用程序。为了与业务层通信，我们使用了一个服务层，Web 层在需要数据时调用该服务层。不幸的是，如果在业务层抛出异常，似乎Web端的服务正在包装异常并重新抛出它们。我们正在寻找一种清晰的方法来封装错误并记录它，而 WCF 不会在原始异常周围包装新异常。

谢谢

我有一个业务层类，它使用 LINQ 将 IQueryable 数据返回到用户层中的 GridView。我希望它只返回一页数据；但是，它返回整个查询。我听说分页应该可以工作，但是每次翻页都会带回数百或数千行，并抛出除 pagesize 中设置的行之外的所有行。

这是 LINQ 查询（稍作编辑）

这是 GridView：

这是加载 Gridview 的代码：

以及执行分页的代码：

我正在开发一个 Web 应用程序，旨在根据用户选择的条件查询大型数据库表。在某些情况下，他们可能知道并输入主键，有时他们可能希望查看abc过去 7 天内创建的状态记录，或者fred smith在描述中包含单词的位置创建的记录proposal。关键是，根据他们正在寻找的内容，他们可以轻松指定 10 到 20 个不同的变量。

构建 SQL 语句并在网页后面的代码中动态应用参数对我来说很容易 ( aspx.cs)。这种方法效果很好。

但是，我一直在阅读有关使用 BLL 和 DAL（甚至只是 DAL）的内容，但我所看到的所有示例都是微不足道的，没有参数，例如getCategories()或单个参数，例如getProductByID(int productID)

所以我想要建议的是如何最好地将我的许多参数的变量列表传递给 BLL/DAL，而无需使用具有（例如）20 个参数的方法（这是可行的，但看起来非常笨拙，特别是如果一个新的选择参数是添加）。

我想到的其他想法是

1. 构建可以在方法中解码的单个字符串参数，例如：

（可行，但可怕且容易出错）

2. 使用结构或类作为参数，例如

DAL 访问此结构/类是否存在问题？我读过 DAL 不应该与调用它的类共享任何引用？

感谢您提供有关如何实施此方案的任何建议。

我来自存储过程并手动创建数据访问层。我试图了解我应该在哪里将 Linq To SQL 或实体框架纳入我的正常计划。我通常将业务层与 DAL 层分开，并在两者之间使用存储库。

似乎人们要么使用生成的从 linq 到 sql 的类，通过使用部分类来扩展它们，要么进行完全分离并将生成的 linq 类映射到单独的业务实体。我偏爱单独的商业实体。然而，这似乎违反直觉。

我最近的一个项目使用了 DDD 和实体框架。当需要更新一个对象时，它将业务实体移动到 repistory 层，当进入 DAL 层时，它将创建一个上下文，然后重新查询该对象。它会比更新值和 resbumit。

我没有看到重要的一点，因为数据上下文没有被保存，并且在更新之前需要一个额外的查询来获取对象。通常我会做更新（如果并发不是问题）

所以我的问题归结为：

1. 将 linq to sql 生成的类分离到业务实体中是否有意义？
2. 应该保存数据上下文还是不切实际？

感谢您的时间，试图确保我理解。我通常喜欢分开，因为即使在一些较小的项目中也能更清楚地理解。

我有一个现有的应用程序，其中包含一个数据层（主要 EF4）、一个业务层（自定义代码）和一个 Windows 应用程序 - 现在我想使用 ASP.NET MVC 创建一个 Web 应用程序，但我不确定具体要做什么，尤其是在我的模型中。

当我的数据和业务逻辑已经存在时，与 MVC Music Store v2.0 (http://mvcmusicstore.codeplex.com/) 等参考项目相比，我应该如何构建我的模型和控制器？我所有的实体都存储在我的数据层中，我所有的方法和逻辑都存储在我的业务层中，所以我想我不需要模型（除非我需要特定的网络模型），我想我的控制器只需要调用我的业务层中的方法我会在一个普通的网络表单应用程序中吗？

另一个问题，如果我需要在 1 页上显示 2 个包含来自 2 个不同实体的数据的列表，我想我需要创建具有 2 个属性的 af 模型（每个实体一个）？

现在的最后一个，如果由于某种原因，例如来自我的业务层的 Get 方法返回异常，应该如何在我的控制器/视图中处理？

什么是软件架构中的领域对象和领域服务？我不熟悉它们，或者它们与业务逻辑层有何不同？

我们正在重新设计一个脱节的实时 OPC 系统，该系统已被证明很麻烦。我们的技术堆栈是 C#、.NET 4 和 SQL Server 2008 R2，托管在 32 位 Windows Server 2003 上。物理架构目前规定所有层都托管在单个服务器上，尽管有足够的动力（阅读：ROI）这可能增加到2。

现有的基本架构是：

• 外部 OPC 设备调用我们的 Web 服务以使用实时数据填充 SQL，大约每秒 300 个事件。我们在这里无法控制容量或批处理，尽管在重写时我想在 Web 服务中实现批处理，以使 SQL 免受每秒 300 个插入语句的影响。
• SQL 被用作执行从警报到报告的任务的各种组件（总共大约 9 个，全部重新设计）的中心资源。这是目前现有设计的最大问题，因为所有这些组件都没有通过单个 BLL 甚至 DAL 来消费/操作数据或管理行为。
• 组件范围从 Windows 服务到 Web 服务再到 Windows 应用程序。CPU 时间和 SQL 连接的最大消耗者是一个 Windows 窗体应用程序，它监视所有实时数据并根据需要发出警报。它还可以生成实时趋势图，运行起来非常昂贵。

对于重写，对 WPF 的推动力很大，除了学习曲线之外，我没有任何问题。我的问题更关心底层架构：

• 我目前正在研究如何实现单个 DAL 和 BLL。对于 DAL，我倾向于 EF 或 nHibernate，Linq-to-SQL 也是一种可能。
• 对于 BLL，我只有 CSLA.NET 方面的经验，我担心这对于速度和资源消耗至关重要的系统来说可能有点过头了。

是否有人对类似系统有任何经验，并愿意分享一些经验教训或设计指南？

我有以下代码：

但我不知道为什么会出现这些错误：

我该如何解决这些错误？

我正在创建一个应用程序，该应用程序分为数据层（使用存储库模式和 EF 4.0）、业务层（带有附加逻辑的 POCO）和服务层（使用 WCF 向客户端公开）。

当我将记录保存到数据库时，我需要检查一下我是在更新现有记录还是插入新记录。该责任应该在哪里 - 在服务层中，以便明确管理对象的生命周期，或者在数据层中，以便保存记录将隐含地确定要采取的操作。

欢迎所有评论 - 我无法决定自己！