问题标签 [n-tier-architecture]

我最近问了这个问题：Expose XML or Objects - 感谢大家的回复。

有一点要澄清。

• API 将始终被远程访问（即作为服务），最有可能通过 web 服务或 WCF。

我同意从理论上讲，将对象公开为输入/输出的强类型 API 是正确的方法。但是，我觉得公开 XML 仍有争议。在我看来，使用 XML 的原因是：

1. 业务规则可以由 Schematron 中的业务分析师编写。
2. 该接口是弱类型的，但只要调用它，就可以根据数据和业务规则验证数据。
3. 服务的实现会更简单。不需要创建域对象模型。
4. XML 模式已经定义（我们有一个模式的数据字典）。

5. 使用 Web 服务技术意味着基于 XML 的 API 不需要在添加新的汽车“类型”时进行更改，例如

   如果我们使用基于对象的 API，那么添加新类型将需要一个新的查询方法来定义可以返回的可能派生类型（请参阅扩展 Web 服务）。像这样更新 Web 服务需要重新构建和重新部署此服务和所有现有客户端。

基于对象的 API 给我们带来了什么？一个强类型的声明式接口。它没有提供比 XML 更多的抽象（XML 本身就是一种抽象）。基于对象的 API 的成本是多少？它需要一整套需要业务规则和数据验证的域对象。

那么，我的问题是什么？给我一个不可战胜的、无可争辩的理由，为什么我应该选择对象。

哪些书籍帮助您掌握了 n 层开发（表示层、UI 业务对象、数据业务对象和数据集）？

我更喜欢书籍，但博客和其他网站也是受欢迎的建议。我在一份新工作中继承了一个 n 层设计的应用程序，虽然我花了一些时间来适应它，但我看到了这些概念的用处。展望未来，我想确保我的开发符合相同的标准。专注于 C# 也会很棒。

此外，您是否会建议其他设计模式以实现可伸缩性？您可以为这些设计模式提供任何建议的阅读材料吗？

我是一名学生，目前正在涉足使用 Nhibernate+WCF+WPF 的 .Net n-tier 应用程序。

其中一件非常糟糕的事情是对象图序列化，事实上它根本没有完成，目前关联被忽略了，我们到处都在使用 DTO。

据我所知，一种方法是预定义应该加载和序列化哪些对象和集合以通过网络，从而能够向客户端呈现一些关联，但这似乎是有限的、不灵活的和不一致的（你能告诉我不喜欢这个主意）。

我想到的一个选择是简单地将客户端层上延迟加载收集的 NHProxies 替换为“disconnectedProxy”，该代理将通过网络检索相关联的内容。这意味着我们必须稍微扩展我们的 Web 服务签名并对我们生成的代理做一些黑客攻击，但这似乎是一个很好的 T4/其他代码生成实验。

据我所知，这似乎是一个常见的绊脚石，但经过大量阅读后，我无法找出任何好的/普遍接受的解决方案。我正在寻找与任何特定解决方案一样多的方向，但如果有一种简单的方法可以让客户“感觉”连接，请告诉我。

因此，根据我上一个问题的答案，如果在事务期间打开多个连接，即使这些连接都具有相同的连接字符串，事务也会从 LTM 提升到 DTC 。

那么，我的下一个问题是，可以采用哪些策略来避免这种“功能”？在我看来，根据资源使用情况，我想确保尽可能多地使用 LTM。在正确面向对象的业务逻辑层中，我能想到的唯一方法是在数据访问层创建一个请求级静态连接对象，并在调用之间共享该对象，直到请求完成（这里的隐含知识是业务对象实体是谨慎的并且不知道它们会被调用的顺序，另外一个事实是人们不希望将连接对象冒泡到业务对象层，因为那将是数据存储实现细节渗入另一层）。

还有其他人有什么想法不会完全破坏 n 层系统的层封装吗？

问候，

提前道歉，我没有认真研究这个问题来自己回答这个问题，但我想这需要一些时间，我宁愿现在知道，然后再投入更多时间来学习它。我在最初的研究中找不到任何东西..

如果您已经在使用多层架构（数据层、逻辑层、表示层），为什么还要使用 ASP.Net MVC？除了控制器比逻辑层拥有更多权力之外。

我是否认为我可以在 MVC 的模型部分中使用 nHibernate 和我的所有数据访问类、实体和映射？

使用控制器时，是否最好将大量逻辑分离到一个单独的类中，以便我可以从多个控制器中调用它？或者我可以从控制器本身调用它们，考虑到我不希望它们都是动作，只是普通方法。

谢谢

我有一个返回数据表的数据层选择方法。它是从一个业务层方法调用的，然后应该返回一个强类型的泛型列表。

我想做的与这个问题非常相似（但不一样）：
How do you convert a DataTable into a generic list?

不同的是我希望列表包含强类型对象而不是数据行（另外，我这里还没有可用的 linq）。

我担心性能。业务层方法将依次从表示层调用，结果将被迭代以显示给用户。在业务层添加一个额外的迭代似乎非常浪费，只是为了演示而立即再做一次，所以我希望这尽可能快。

这是一个常见的任务，所以我真的在寻找一个可以一遍又一遍地重复的好模式。

多年来，我注意到不同的开发人员对 n 层系统开发中的层构成有不同的标准，所以我很好奇 stackoverflow 的共识是什么。

单独的逻辑层是否足以将其称为单独的层，还是必须可部署在单独的服务器（物理或虚拟）上才能将其称为单独的层？

让我用不同的方式来表达这个问题。如果调用机制只能在进程中、线程本地或单元本地，那么根据类如何组织到库或包中，是否可以声称它是两个不同的层？

我刚刚遇到以下句子：

随着行业从三层模型转变为 n 层模型，对象关系阻抗失配变得更加普遍。

但是我找不到三层和n层之间区别的简明解释。我知道三层是什么，我假设 n 层只是增加一层或多层。我只是不确定这些额外的层级是什么。如果有人有简短的解释或只是一个好的链接，那将不胜感激。

我想在我正在构建的应用程序中使用 SubSonic (2.2)，因为我喜欢它的简单性，并且它可以处理我可以预见需要的任何类型的查询。同时，我想让我的应用程序的上层与 Subsonic 类型分离。我想只返回普通的旧 C# 对象，并传入要保存的 POCO。

但这里有个问题：我希望我的 POCO 根据 FK 关系为子集合和父对象延迟加载属性。我想我需要以某种方式将 Subsonic SqlQuery 对象放在我的 POCO 的私有成员中，并在 getter 内部使用它来获取延迟加载的属性。

关于如何使用 SubSonic 专门实现这一点的任何想法？以前有人做过吗？

我确实意识到 SubSonic 的下一个主要版本将立即执行此操作，但这看起来至少需要几个月的时间。

刚刚读完Greg Young 的这篇文章，他在其中谈论 Microsoft 推荐带有哑数据传输对象的模式。他暗示，在 Java 社区中，事情正朝着另一个方向发展。

我的问题是您的实体对象中应该有多少逻辑？我工作的地方（C# 商店）的理念是，如果你不能序列化它，就不要把它放在实体中。