我有一个 WCF svc，分为服务层、业务逻辑层和数据访问层。

当我的 DAL 遇到异常时，我应该在那里捕获它还是让它冒泡回到服务层？为什么？

请忽略此方案的任何客户参与，我只关心在 WCF svc 上记录异常。

我需要能够收紧我的业务层——访问特定数据。UI 可以调用业务层并接收用户详细信息。然后 UI 可以对用户调用 .Save() ，业务层将调用数据访问层来保存用户。

虽然，这里的问题是我不只是希望任何用户能够接收用户详细信息并调用保存 - 只有具有“管理员”角色的经过身份验证的用户。我将如何在我的业务层/UI 中进行此身份验证/授权，以便实现此目的？

我正在为我的 UI 使用 ASP.NET，并且我已经阅读了成员资格/角色提供程序，但这似乎只是针对实际 UI。我需要在我的业务层保护它，因为将来可能会有几个不同的 UI。例如 windows 窗体和 Asp.net。

想法和建议表示赞赏。

谢谢。

我正在开发一个软件，其中有一些实体，例如：

这些是我的 EF4 POCO 对象。我正在使用存储库模式和以下界面：

存储库有一个内部 ObjectContext。我有一个 UnitOfWork 包含我的存储库的实例，并负责保存对它们所做的更改。

到目前为止我做得对吗？

我正在实现这样的业务逻辑层：

现在我不确定我是否朝着正确的方向前进。我的 POCO （将）负责验证，并使我能够做类似的事情

由于这些对象与上下文相关联，当我保存它们时，对集合的更改是否也会保存在数据库中？

另外，我希望我的 Playgrounds 不能在没有 Workspace 的情况下创建，而 Services 则不能在没有 Playground 的情况下创建。我应该在哪里创建和删除它们？

谢谢。

对于我的开发选择，我是 NTiers 的忠实粉丝，当然它并不适合所有场景。

我目前正在做一个新项目，我正在尝试以我通常的工作方式进行游戏，并尝试看看我是否可以清理它。因为我一直是一个非常糟糕的男孩，并且在表示层中放置了太多代码。

我正常的业务层结构是这样的（它的基本观点）：

• 商业
  • 服务
    • FooComponent
      • FooHelpers
      • FooWorkflows
    • Bah组件
      • BahHelpers
      • Bah工作流
  • 实用程序
    • 常见的
    • 异常处理程序
    • 进口商
    • ETC...

现在有了上面的内容，我可以通过它们各自的助手直接保存 Foo 对象和 Bah 对象。

XXXHelpers 让我可以访问保存、编辑和加载相应的对象，但是我应该将逻辑与子对象一起保存在哪里。

例如：

我们有以下对象（我知道不是很好的对象）

• 员工
• 员工详情
• 员工会员
• 员工简介

目前我会在表示层构建这些，然后将它们传递给他们的助手，我觉得这是错误的，我认为数据应该传递到业务层某个地方的表示之上的一个点并在那里进行整理。

但是我有点不知所措，我将把这个逻辑放在哪里以及如何称呼这个部门，它会作为 EmployeeManager 或类似的东西归入 Utilities 下吗？

你会怎么办？我知道这都是偏好。

更详细的布局

工作流包含直接对 DataRepository 的所有调用，例如：

然后助手提供对工作流的访问：

这是为了减少重复代码，因为您可以在工作流中调用一次 getBySomeProperty，然后在 Helper 中调用几次，这些调用可以执行其他操作并以不同方式返回数据，一个不好的例子是 public GetByIdAsc 和 GetByIdDesc

通过使用 DataRepository 分离对数据模型的调用，这意味着可以将模型换成另一个实例（这是想法），但 ProviderHelper 尚未分解，因此它不可互换，因为它是不幸的是，硬编码到 EF。我不打算改变访问技术，但将来可能会有更好的东西，或者只是所有酷孩子现在都在使用的东西，我可能想要实现。

项目名称.Core

项目名称.演示文稿

（取决于应用程序的调用是什么）

测试项目

一个简单的 linq to SQL 查询可能会返回一个产品对象。显然我可以将此对象传递给我的业务层，然后直接针对该对象读取和更新数据。

我见过一堆实现，在执行 linq 查询之后，结果对象被映射（通过自动映射器或手动）到自定义业务对象。因此，对于我可能拥有 linq 对象的产品：

product.ProductId 和 Product.ProductName

然后我会像这样定义一个自定义产品业务对象：

和一些简单的映射代码，如：

业务产品 myProduct = 新业务产品（）；myProduct.ProductId = 产品.ProductId; myProduct.ProductName = 产品.ProductName;

然后在我的业务层周围传递 myProduct ，修改它，读取它等等，然后更新 linq 对象。

在什么情况下我想创建自定义 BusinessProduct 类？

日期 创建了一个我感兴趣的特定示例 - 但还有其他一些属于同一类别的数据：您想要捕获的关于任何模糊重要实体的数据。

最好在哪里执行此操作：业务逻辑 (BL) 或数据访问层 (DAL)？

到目前为止，我一直依赖 SQL Servergetdate()来填充为我创建的插入到表中的日期，但现在我开始怀疑我是否应该在 BL 中做更多的事情。

仅供参考 - 这主要是在基于 Web 的系统中，您在 BL 中创建一个对象（基于用户输入）并在 DAL 中触发它 - 这不像我多年来一直想要引用内存中的对象（因此在对象上具有“创建日期”属性以在创建对象时在 BL 中使用不是问题）。

也许还有第三种选择 - 在阅读 Marr75 的回答后，我想到记录两次可能在某些场景中有用（在两个位置一次）。您将受益于数据层中一致的日期/时间，但您仍然可以参考 BL 驱动值 - 我想我将取决于您的用例。不过，此选项并非没有风险——人们可能会开始为错误的事情使用错误的日期。

当我开始使用 ASP.NET 编写 Web 应用程序时，我开始使用使用 Linq-To-SQL 映射器来访问 MSSQL Server 的数据库的小项目。
在获得了一些经验之后，我切换到了经典的三层方法，即图形层、业务层和数据层。数据层的唯一功能是提供插入/更新/删除方法，没有任何逻辑和逻辑选择方法的形式。

随着时间的推移，我意识到最好不要将数据库类提供给 GUI（不幸的是花了一些时间）。我切换到在 BL 中使用业务类，这些业务类用于 BL 执行的所有操作，并由 GUI 以从业务层获取列表的形式显示。
一个很大的优势是我可以提供数据库本身没有表示的其他属性。但是，我自己使用将相应业务层类映射到数据库类的方法在业务层内部进行了映射。

我想这就是 O/R 映射器派上用场的地方？直到现在，我还没有意识到他们的目的，但我想我刚刚找到了。我最近尝试将新的实体框架与 .NET Framework 4 一起使用，但我只是像 Linq-To-SQL DataContext 一样使用它。

有没有办法自动实现映射？如果是，那是新实体框架提供的东西，还是我需要寻找像 NHibernate 这样的 O/R 映射器？

让我们假设我有自己的业务层，其中包含我的业务对象和我的业务服务。我决定创建一个“SilverLight 业务应用程序”（使用 SL v 4.0），我想使用我计划开发的 SL 应用程序中已经使用的业务层。

我知道我不能包含一个不是 SL 项目的项目。

你能告诉我我能做到这一点吗？

谢谢

我需要一些关于为我的基于 Web 的业务层功能选择哪些签名的意见：

函数无效 CreateUser（公司用户公司，字符串名称...）

或者

函数 void CreateUser(int CompanyID, string name...)

如果这是基于窗口的，我会选择函数来获取对象而不是 int，因为既然公司已经加载到窗口窗体，为什么不直接使用它。另外，我认为业务层应该采用业务对象并且它的类型是安全的（防止意外传入 0 或 -1）。

但另一方面，如果这是一个基于 Web 的应用程序，则只有 id 会加载到客户端站点。所以加载公司对象有点多余，因为最终只会将公司ID保存在数据库中。

希望我的描述不会太混乱 =P 感谢您的阅读。

我知道这听起来可能很愚蠢，但我发现很难理解服务层的需求及其与业务层的区别。

因此，我们使用 asp.net mvc 2 并拥有数据访问层，它对数据库进行所有查询，然后我们拥有业务层，它具有需要完成的业务逻辑和验证。最后，我们有了基本上拥有所有视图的表示层。此外，作为我们库的一部分，我们还在不同的文件夹中提供了一些帮助程序、DTO 和视图模型类。但是我尝试阅读有关架构的内容，并且似乎服务层是架构的重要组成部分。

我所理解的是，服务层是调用所有功能的东西。但是我真的看不到我们的应用程序需要服务层吗？或者它可能已经存在并且我看不到它......任何人都可以用一个例子来解释服务层的重要性吗？它与业务层有何不同，因为从我所读到的内容看起来非常相似？如果它是第一个需要的？我们要做的就是以最好的方式构建我们的应用程序，您对此有何想法和经验？