问题标签 [three-tier]

我正在寻找一个 asp.net 网站（带有源代码）的示例，它采用 3 层架构实现，并且具有一些复杂性，例如用户身份验证和用户权限等。

有人知道这样的例子吗？

考虑到一个假设的情况，一个旧的、遗留的表示库多年来一直在维护，并且通过仓促更正和缺乏适当的架构监督的过程逐渐将越来越多的业务逻辑编码到其中。或者，考虑一个业务类或命名空间，它没有通过程序集边界与表示分离，因此能够引用 System.Windows.Forms 之类的东西而无需强制添加引用（比简单的 using 子句更清醒的操作） .

在这种情况下，这个 UI 代码使用的业务代码最终会被调用以进行重用并非不可想象。将两层分开以实现这一点的好方法是什么？

我对设计模式非常熟悉——至少在原则上是这样。但是，我没有大量的实践经验，所以我有点不确定自己的直觉。我已经开始为此使用策略模式。这个想法是识别业务逻辑调用 UI 组件以向用户提出问题并收集数据的位置，然后将它们封装到一组接口中。该接口上的每个方法都将包含来自原始工作流的面向 UI 的代码，然后 UI 类将实现该接口。

想要重用相关业务逻辑的新代码也将实现此接口，但替换新窗口或可能的预制或参数化答案来回答最初由 UI 组件回答的问题。这样，商务逻辑可以被视为一个真正的库，尽管传递给它的某些方法的接口参数有些尴尬。

这是一个体面的方法吗？我应该如何更好地解决这个问题？我将听从您的集体互联网智慧。

谢谢！

每次我开始开发新的 ASP.NET MVC Web 应用程序时，我都不确定是否要使用DataAnnotations验证。感觉有些不对劲。

例如，假设我有UserService一个CreateUserModel从. 为了确保用户始终提供名称，我将模型的属性设置为具有该属性。我现在知道模型活页夹永远不会给我 a除非它有一个名字。CreateAccountControllerName[Required]CreateUserModel

我的问题是，要让我UserService成为系统的可重用组件，它不能依赖于上面的层提供有效数据的事实，而且肯定还必须验证这些数据。当您考虑到您可能想要编写一个完全重用的 Web 服务UserService（并且不会让模型绑定器为其执行所有数据注释验证）时，对此的需求会进一步突出。

所以我的问题是：这种情况的最佳做法是什么？使用数据注释进行验证并在服务中重复该验证？仅在服务中验证并抛出异常？两者的混合？

我希望我的问题不是太主观，我主要是想就将验证转移到数据注释是否最终会咬我一口达成共识。

当我开始开发一个新的 Web 应用程序时，我倾向于使用经过试验和测试的 ASP.NET MVC、BLL（由一组包含所有业务逻辑的服务组成）和一个 DAL（由一组存储库组成）的相同架构这促进了工作单元模式而不是像EF /*Linq to SQL*) 这样的东西。

控制器仅与服务对话，服务仅与存储库和其他服务对话。在服务层是定义模型的地方，这些模型用作控制器的输入/输出。

我的问题是：其他人在做什么？我很想知道人们是否在 ASP.NET MVC Web 应用程序的上下文中做任何不同的事情。例如，有CQRS和Domain Events等概念。有没有人使用这些来解决我上面描述的方法的问题？

这个问题主要是试图发现我不知道我不知道的东西的来源。我希望这不是太模糊，但我认为重要的是要看看别人在做什么来评估你自己的方法。

众所周知，三层架构由表示层，业务逻辑和数据库层组成，业务规则（如：存储过程，触发器......）存储在数据库层中，所以当我们想要更换数据库引擎时（如 ms sqlserver）和新的数据库引擎（如 oracle）这些规则必须转移到新的数据库引擎。

我的问题是我们如何自动传输这些规则而不是为新引擎重写它们？

我从事过一个实现三层架构的项目，其设计如下：

1. 表示层 -使用带有 MVC 框架的 PHP 来处理前端表示和业务逻辑。该层调用访问数据的服务层。
2. 数据访问层 -使用 C# .NET 并分为服务、业务逻辑和数据层。由表示层调用。调用数据库并序列化响应以返回到表示层。
3. 数据层 -数据库。提供上述两层的所有数据。

我知道三层方法可以提高安全性，因为如果表示层受到破坏，仍然无法访问数据。虽然这是真的，但这种方法似乎有点过于复杂，特别是因为我被迫在前两层为同一个对象编写两个模型。

所以我的问题是：这是一个糟糕的三层架构实现吗？如果是这样，如何改进？简单地拥有一个可以访问数据库的 MVC 实现有哪些缺点（如果有的话）？您的 Web 应用程序使用什么方法？

谢谢您的帮助！

MVC 和 3 层架构之间的基本区别是什么？

我正在写一篇关于数据库应用程序方面的两层和三层架构的比较文章。我只想确认几件事。

2 层是客户端 - 服务器 2 层是客户端上的应用程序 - 服务器上的数据库。2层实现直接通信。基于直接通信的安全性差？然而，适用于用户少于 50 人的小型基于 Intranet 的环境。

就用户界面而言，两层通常使用 Java 应用程序（即 Swing），而三层则使用 Web 浏览器？

3层更具可扩展性。3 层使用中间层更安全。3 层是客户端 - Web 服务器 - 数据库服务器

我希望你们能反驳我所写的大部分内容，并揭露一些我需要进一步研究的领域。

谢谢

硅

因此，您不仅可以随意回答这个问题，还可以提出建议或改进。我以前从未组装过大型 Web 应用程序。这是我的思考过程：

• 持久层：标准数据库（现在是 MySQL）
• 业务逻辑层：类 REST 结构（PHP、Java Servlets 等...）
• 表示层：Web 浏览器、Android 设备（应用程序而非浏览器）等

我选择这种架构的原因是，设备可以设计自己的自定义 UI，并通过使用 GET、POST 以及不与服务器交互的内容来利用类似 REST 的功能。

问题1：

问题是，您如何保护用户的信息？您可以通过 SSL 连接对用户进行身份验证并返回一个特殊的 HASH，以便用户可以操纵他们的帐户，但如果有人在网络上监听，他们所要做的就是监听 REST 调用并窃取 HASH。一种解决方案是所有类似 REST 的调用都必须通过 SSL，但这会导致另一个问题。

问题2：

如果 REST 程序在 SSL 中，则浏览器必须对所有内容使用 SSL，据我了解，这在不必要时可能会很慢而且很麻烦。此外，SOP 使得无法从不安全的浏览器对 REST 过程使用 SSL ajax 调用。HTTP 和 HTTPS 被认为是不同的来源，即使它的来源相同，协议不同。

这个解决方案可行吗？我将如何解决这两个问题？或者可能（可能）我应该为我的 Web 应用程序寻找更好的架构。提前感谢所有建议。

我喜欢在 Java 中使用三层（数据/业务逻辑|服务/ui），并希望将其应用于 PHP 中的网站。在这方面你能提出什么建议、链接、教程？

PS：我对如何编写和使用域/实体对象特别感兴趣。