棱镜与 ASP.NET
我的公司正在研究 ASP.NET 和 Prism。我们想知道这两个选项之间可以重用多少代码。
在我看来，Prism 有这些“部分”：
- Shell（Bootstrapper 等）
- 模块
- 服务（不是 Web 服务）
- 区域
- 松散耦合事件（IEventAggregator）
- Unity（虽然实际上这是一个独立的产品）
在我看来，唯一的绝对必须与 Silverlight/WPF 一起使用的部分是区域。
shell 可能有点棘手，但我认为它可以在 ASP.NET 应用程序中完成。我还认为模块（非区域提供模块）也应该是可行的。使用 IEventAggregator 和 Unity 应该很容易。
我唯一的问题是我在 ASP.NET 编程方面并没有真正的经验，所以我不确定我的假设。在对此问题的讨论全面展开之前（在我的公司），我希望熟悉 Prism 和 ASP.NET 的人提供一些反馈。
基本上，我想制作将运行网络服务和业务逻辑的 Prism 模块。然后，我想获取这些模块并在 ASP.NET 应用程序和 WPF/Silverlight Prism 模块（通过区域）中（重新）使用它们。
我是否通过尝试合并这两个系统来绘制一个艰难的旅程？
My company is looking into ASP.NET and Prism. We are wondering how much code reuse we can get between the two options.
As I see it Prism has these "parts":
- Shell (Bootstrapper and such)
- Modules
- Services (not web-services)
- Regions
- Loosely Coupled Events (IEventAggregator)
- Unity (though really this is a standalone product)
As I look at this, the only part that absolutely must be used with Silverlight/WPF is Regions.
The shell may be a bit tricky, but I think It could be done in an ASP.NET app. I also think that Modules (non-Region offering modules) should also be doable. Using IEventAggregator and Unity should be easy.
The only problem I have is that I am not really experienced in ASP.NET programming, so I am not sure of my assumptions. I would love some feed back from someone who is familiar with both Prism and ASP.NET before the discussion on this goes into full swing (here at my company), .
Basically, I want to make Prism modules that will run web-services and business logic. I then want to take these modules and (re)use them in ASP.NET apps and WPF/Silverlight Prism Modules (via Regions).
Am I charting a difficult journey by trying to merge these two systems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您将遇到的问题是客户端应用程序和 Web 应用程序之间不同的生命周期样式。
Web 应用程序基本上是无状态的 - 对象图已建立，请求得到满足，然后所有内容都被丢弃。编写网络应用程序时必须假设许多不同的用户同时使用它。
另一方面，客户端应用程序启动、设置其环境，然后将所有内容保留在内存中。此外，客户端应用程序实例将有一个用户，而不是多个。 shell 和 EventAggregator 特别依赖于内存中保留的所有内容，甚至跨请求，并且不区分谁在工作（因为在那个世界中，只有一个）。
我认为您只需在正确的位置连接 DI 容器并编写一些引导代码以在运行时引入代码即可获得您想要的大部分好处。
The problem you're going to run into is the different lifetime styles between client apps and web apps.
Web apps are basically stateless - the object graph is built up, the request is satisfied, and then everything is thrown away. Web apps have to be written assuming that many different users are hitting it at the same time.
Client apps, on the other hand, start up, set up their environment, and then keep everything around in memory. Also, a client app instance will have one user, not many. The shell and the EventAggregator in particular rely on everything sticking around in memory, even across requests, and don't differentiate between who is working (because in that world, there's only ever one).
I think you can get most of the goodness you want just by hooking up a DI container at the right place and writing a bit of bootstrapping code to pull in code at runtime.
如果代码重用是一个大问题（它应该是），那么我会看看您的项目生命周期要求。你需要这个代码来生存几年、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（安全）检索数据的方法。
If code reuse is a big concern (which it should be), then I would look at your project lifetime requirements. Do you need this code to survive a few years, 5 years, 10 years? More? Obviously most big projects want their code to survive as long as possible with as little maintenance (or rewrite) as possible.
The reason I bring this up is that if you write your code modules using Prism or ASP.NET, then you're tying up your (potentially) reusable code into that specific technology, which may or may not be used in 5+ years. This is coupling your long-term code with relatively short-term technology. What happens in several years when the "next big thing" is released, and you'd like to migrate your project to it? If you're coupled to Prism or the current ASP.NET, you may find it fiscally difficult/impossible to switch technologies.
You're better off abstracting your application logic and flow into a top-level, technology-agnostic structure that can be interfaced with Prism and/or ASP.NET. This idea of decoupling is one of the main reasons that IoC/DI containers (like Unity) have become so popular of late. It also makes unit testing a whole lot easier.
In essence, using some application infrastructure (such as N-tier) you'd encapsulate your business logic and data access, while abstracting your user-interface in such a way that it can be reused. Model-View-Presenter also demonstrates abstracting your UI for maximum reuse and unit testing.
An N-tier application infrastructure also shines when you're looking at distributed computing - what happens when you want to run your Prism application on the client's machine, but you want to host your application's data (i.e. a SQL Server Database, for example) on the server? If your client's machine is on your network, that's fine - you can give them a connection string to the server, no problem. But if you plan on accessing your data across the Internet, then you need to abstract your application's data layer and provide methods to (securely) retrieve the data across the Internet.
我对 Chris 的回答投了赞成票，因为它对于普通的 asp.net 来说是 100% 正确的。然而，只要有一点创造力，您也许可以利用 Knockoutjs 更接近您的目标。
I upvoted Chris' answer, because it is 100% correct with vanilla asp.net. However, with a bit of creativity, you may be able to leverage Knockoutjs to get closer to your goal.
我认为你正在走向一个充满伤害的世界。我深入研究了 Prism 代码，发现它并不漂亮，而且与 WPF/Silverlight 紧密相关。这些模型非常不同，共享代码的想法听起来很棒，但我敢打赌这几乎是不可能的。
I think you're heading down a world of hurt. I've dug into the Prism code and it's not pretty and it's closely tied to WPF/Silverlight. The models are very different and the thought of sharing code sounds great, but I bet will be next to impossible.