带有 ASP.NET 的棱镜

Question

我的公司正在研究 ASP.NET 和 Prism。我们想知道在这两个选项之间我们可以获得多少代码重用。

在我看来，Prism 有这些“部分”：

• Shell（引导程序等）
• 模块
• 服务（不是网络服务）
• 地区
• 松散耦合事件 (IEventAggregator)
• Unity（虽然这确实是一个独立的产品）

在我看来，Silverlight/WPF 绝对必须使用的唯一部分是区域。

shell 可能有点棘手，但我认为它可以在 ASP.NET 应用程序中完成。我也认为模块（非区域提供模块）也应该是可行的。使用 IEventAggregator 和 Unity 应该很容易。

我唯一的问题是我没有真正的 ASP.NET 编程经验，所以我不确定我的假设。在有关此问题的讨论全面展开之前（在我的公司），我希望从熟悉 Prism 和 ASP.NET 的人那里得到一些反馈，.

基本上，我想制作能够运行 Web 服务和业务逻辑的 Prism 模块。然后，我想采用这些模块并（重新）在 ASP.NET 应用程序和 WPF/Silverlight Prism 模块（通过区域）中使用它们。

我是否通过尝试合并这两个系统来制定一段艰难的旅程？

Answer 1

您将遇到的问题是客户端应用程序和 Web 应用程序之间不同的生命周期样式。

Web 应用程序基本上是无状态的 - 构建对象图，满足请求，然后丢弃所有内容。必须假设许多不同的用户同时点击它来编写 Web 应用程序。

另一方面，客户端应用程序会启动、设置其环境，然后将所有内容保存在内存中。此外，客户端应用程序实例将有一个用户，而不是很多。 shell 和 EventAggregator 尤其依赖于内存中的所有内容，甚至跨越请求，并且不区分谁在工作（因为在那个世界中，只有一个）。

我认为你可以通过在正确的位置连接一个 DI 容器并编写一些引导代码在运行时拉入代码来获得你想要的大部分优点。

Answer 2

如果代码重用是一个大问题（应该是），那么我会看看您的项目生命周期要求。您是否需要此代码才能存活几年、5 年、10 年？更多的？显然，大多数大型项目都希望他们的代码在尽可能少的维护（或重写）的情况下尽可能长久地存在。

我提出这个问题的原因是，如果您使用 Prism 或 ASP.NET 编写代码模块，那么您将（可能）可重用的代码绑定到该特定技术中，这可能会或可能不会在 5 + 年。这是将您的长期代码与相对短期的技术相结合。几年后“下一件大事”发布时会发生什么，您想将项目迁移到它？如果您与 Prism 或当前的 ASP.NET 耦合，您可能会发现切换技术在财务上很困难/不可能。

您最好将您的应用程序逻辑抽象化并流入可与 Prism 和/或 ASP.NET 接口的顶级、与技术无关的结构。这种解耦的想法是 IoC/DI 容器（如 Unity）最近变得如此流行的主要原因之一。它还使单元测试变得更加容易。

本质上，使用一些应用程序基础架构（例如N-tier），您将封装您的业务逻辑和数据访问，同时以可以重用的方式抽象您的用户界面。 Model-View-Presenter 还演示了抽象您的 UI 以实现最大程度的重用和单元测试。

当您研究分布式计算时，N 层应用程序基础架构也会大放异彩 - 如果您想在客户端计算机上运行 Prism 应用程序，但又想托管应用程序的数据（即 SQL Server 数据库、例如）在服务器上？如果您的客户机器在您的网络上，那很好——您可以给他们一个连接到服务器的字符串，没问题。但是，如果您计划通过 Internet 访问您的数据，那么您需要抽象应用程序的数据层并提供方法来（安全地）通过 Internet 检索数据。

Answer 3

我赞成 Chris 的回答，因为它在原版 asp.net 中是 100% 正确的。但是，只要有一点创造力，您就可以利用Knockoutjs 来更接近您的目标。

Answer 4

我认为你正在走向一个充满伤害的世界。我已经深入研究了 Prism 代码，它并不漂亮，而且它与 WPF/Silverlight 密切相关。模型非常不同，共享代码的想法听起来很棒，但我敢打赌这几乎是不可能的。