问题标签 [n-tier-architecture]

在寻找资源以成为更好的开发人员时，我正在寻找如何在 n 层应用程序中构建代码的好例子。

比如......业务对象做什么和看什么，它如何与数据访问层接口等。UI 如何与业务层接口，它是否直接与 DAL 接口。

您是否知道值得研究的可免费获得的好例子？

我想知道 MVC（这是一种架构模式）和应用程序的 n 层架构之间到底有什么区别。我搜索了它，但找不到简单的解释。可能是我对 MVC 概念有点天真，所以如果有人能解释其中的区别，那就太好了。

干杯

如何优雅地实现错误处理？例如，我的数据访问层可能会引发 2 种类型的错误：1) 未经授权的访问，在这种情况下，页面应该隐藏所有内容并仅显示错误消息 2) 通知用户此类内容已存在于数据库（例如，名称不是唯一的），在这种情况下，我不想隐藏所有内容。

编辑：

由于这里的一些评论，我设计我应该创建派生的专门异常类型，例如 NotAuthorizedException、DuplicateException 等......这一切都很好，但我可能会看到 2 个问题：

1）每个存储过程都有一个返回字段 p_error ，其中包含错误消息。从 DB 获取数据后，我需要检查该字段以查看返回的错误类型，以便引发适当的异常。所以，我仍然需要将我的错误类型/错误消息存储在某个地方......换句话说，我应该如何向用户提供确切的消息（在某​​些时候我需要）而不先检查 p_error 字段。这让我回到了错误对象。任何人？

2）我可能会变成一场噩梦，其中异常的数量等于错误消息类型的数量。

我在这里错过了什么吗？

非常感谢大家！

我希望你能帮忙。我正在使用 Linq to Sql 开发一个分层网站。我在 DBML 设计器中创建了一个名为 memberState 的新类（或对象）。此对象不是数据库中的实际表。我的中间层有这个方法：

public override IEnumerable(memberState) GetMembersByState(string @state)
{
using (BulletinWizardDataContext context = DataContext)
{
IEnumerable(memberState) mems = (from m in context.Members
join ma in context.MemberAddresses
on m.UserId 等于 ma.UserId
join s在 ma.StateId 上的 context.States
中等于 s.StateId
其中 s.StateName == @state
select new memberState
{
userId = m.UserID,
firstName = m.FirstName,
middleInitial = m.MiddleInitial,
lastName = m.LastName,
createDate = m.CreateDate,
modifyDate = m.ModifyDate
}).ToArray(memberState)();
返回内存；
}
}

我的联接中的表（Members、States 和 MemberAddresses 是我的数据库中的实际表）。我创建了对象 memberStates 以便可以在上面的查询中使用它（注意Select New memberState。当网页上的数据更新时，如何将更改保留回成员表？我的成员表由以下列组成: UserId, FirstName, MiddleInitial, LastName, CreateDate, ModifyDate. 我不确定如何将更改保存回数据库。

谢谢，

我在尝试布局我的 VS 解决方案时遇到问题，我想要一些建议。

目前，我的解决方案布局类似于以下项目：-

我的网站 ( Foo.Web) 调用Foo.Services命名空间上的各种方法。这里的想法是Services处理所有业务逻辑。Model命名空间只是POCO对象。Repositories命名空间是不言自明的。

带有接口的构造函数依赖注入处理了什么层需要什么组件的黑魔法。

问题：我希望在解决方案中添加一些 Windows Workflow Foundation (WWF) 代码，但将此 WWF 代码放在同一个 Foo.Services.dll 中。

为此，我需要制作另一个类型的项目Workflow。此工作流具有调用 Foo.Services 方法的活动。因此，我的网站现在必须调用服务方法或工作流方法来做事。

我希望网站只调用Services命名空间来做事。

毕竟，服务是 UI 和业务逻辑 IMO 之间的主要接口。我在技术上使用 WWF 的事实对于在 IUI 前端编码的人来说不应该是一个问题。

由于工作流dll调用Services dll中的方法，因此Services dll由于循环依赖不能调用Workflow中的方法。

我也无法将所有工作流代码移动到服务 dll 中，因为服务 dll 需要是一些特殊的项目类型（Windows 工作流类型）。

所以..我不知道该怎么办？

我怎样才能使消费者只引用商业内容的服务命名空间，而我在 WWF 中暗示这些商业内容的事实对消费者是隐藏的？

我是否需要制作一个 WWF 项目并将我的所有服务代码移入其中，扔掉旧的服务项目？这样做听起来不太可重用。如果我决定不使用 WWF 来处理某些管道操作并使用其他东西会发生什么？

这里有一些代码可以帮助解释。

谢谢窥视。

我意识到已经有很多关于 n 层设计的帖子，这可能是我在思考问题和绕圈子，但我现在自己都感到困惑，希望从社区中得到一些澄清。

我正在尝试将我创建的项目（并且从一开始就没有很好地设计架构）分成不同的层（每个层都在他们自己的项目中）：

• 用户界面
• 业务对象
• 逻辑/业务
• 达尔

UI应该只调用逻辑层来获取它的东西

业务对象不应调用或引用其他任何东西，只是存储数据的一种方式

逻辑/业务层应该包含系统中获取、创建、更新、删除 (CRUD) 对象的所有方法，并且可以引用 BO 和 DAL 。它将业务逻辑应用于操作，然后将实际的 CRUD 委托给 DAL。

DAL只会在数据库上执行 CRUD 操作。它将引用 BO，因为它会为 Gets 等返回它们。

我的问题是逻辑类是否应该只调用其等效的 DAL 类而只调用逻辑类？换句话说，CompanyLogic类应该只调用CompanyDAL类。因此，如果它想通过 ID 获取 Client 对象，它将调用ClientLogic.GetClientByID(int)而不是ClientDAL.GetClientByID(int).

我认为它可能应该留在自己的层的原因是：

1. 这似乎会放松项目之间的耦合

2. 逻辑呢，如果获取客户端对象中有一些逻辑验证（可能不是最好的例子，但希望它能够理解这一点）。

编辑：

我不确定这是否是我的糟糕设计，但目前业务层有许多类，包括 ClientBULL 和 CompnayBULL，这两个类相互调用。我为每个类使用一个接口，并有一个工厂来构建对象以尝试减少任何耦合，但由于在两个类中调用方法，它们现在不能没有彼此而存在。这是一个坏主意吗？

我为一个有点落伍的大型州政府机构工作。我们的技能已经过时，预算冻结阻止了对新员工/顾问的任何培训或雇用（解雇人员也是不可能的）。设计业务对象、实现设计模式、建立代码库和服务、单元测试、源代码控制等都是您在这里找不到的事情。我们在 Joel 测试中的得分尽可能为 0。好消息是我们只能从这里上去！

我们开发直接通过 ODBC 连接访问 Oracle 数据库的桌面 CRUD 应用程序（使用 C++、C# 或 Java）。我们基本上在 GUI 上散布着 SQL 语句和拼凑代码。我们被告知要转向面向服务的 n 层架构，以防止直接访问数据库并消除用户计算机上的 Oracle 客户端需求。

WCF 是我们应该走的路吗？我们已经完成了一些 n 层应用程序演练（例如这个），它们似乎很容易实现，但我们只是不知道我们是否正在考虑正确的技术。利用 .NET 生成的类型化 DataSet 似乎是一个不错的权宜之计，可以节省我们数月/数年的工作（而不是从头开始为众多项目创建新的业务对象）。这种罐装方法在第一步是否可行？

我的一个朋友在 3-Tier 应用程序设计和开发方面没有太多经验，他想扩展他在这个主题上的知识。你能给我指出好的在线资源或书籍吗？如果他们从原则开始，那就太好了。我认为本教程是一个很好的起点。

你最喜欢什么资源？

干杯。

大家好，我对分层开发过程很陌生。我目前正在开发一个应用程序，我有一些关于当今技术的最佳实践/架构问题的基本问题。我将使用 WCF 作为服务层。请注意，我正在尝试尽可能多地解耦。我不希望上层的任何事情都必须了解下层的任何事情，这是我不喜欢 LINQ TO SQL 或实体框架的原因之一。

1) 在层之间传递数据的最佳方式是什么？我知道数据集或数据表都很容易，但我认为在层之间传递这种臃肿的数据结构并不是最好的解决方案。如果数据表/数据集很大，调试也会更加困难。一组 POCO 对象可能是最好的解决方案还是有更好的方法？

2）下一个问题有点棘手。许多应用程序会有一堆不同的数据视图。您可能有多个报告、各种数据网格，可能还有一个或两个图表。您如何为此设计数据层？您是否只是为每个表设计一个“获取”类型的函数，然后尝试将它们组合成有用的视图，例如您的业务层中的网格或报表，或者您是否为业务层中需要的每个视图提供了专门的功能。

老实说，我不喜欢这两种解决方案。如果您决定每个视图的专用逻辑，那么您需要为每个视图创建一个 POCO 对象（假设您将返回一个 POCO 对象数组）。如果您稍后决定需要向其中一个视图添加更多列，那么您将破坏现有代码（因为您更改了 POCO 上的界面）。如果您决定返回每个表的视图并尝试将其组合到业务层中，那可能会变得非常混乱。TSQL 有连接是有原因的:)。此外，您可能会返回比您需要的更多的数据，具体取决于您的设计，这将是低效的。

我还有一些问题，但我会留到以后。我不希望这篇文章变得太大:)

笼子

我创建了一个 n 层解决方案，我从 WCF 服务检索相关数据，在 Windows 窗体应用程序中更新它，然后通过 WCF 返回更新的数据以持久保存到数据库。应用程序、WCF 服务和数据库都在不同的机器上。

正在检索的数据由一个对象和子对象组成...

客户端应用程序应用的更新除了更新现有内容外，还可以插入额外的“跟踪”对象。

当我从客户端应用程序接收到 Product 对象时，我可以正确看到所有更新，但是为了正确保存所有更改，我必须跳过几个环节......

当然，必须有一种更简单的方法来做到这一点？

注意：我花了下午的大部分时间调查 EntityBag 项目，但发现它尚未更新为与 EF RTM 一起使用。特别是，虽然它会成功更新现有数据，但在混合新对象时会引发异常。