【问题标题】:Multiple Application in Single AppDomain单个 AppDomain 中的多个应用程序
【发布时间】:2012-04-30 22:48:34
【问题描述】:

我是一名 Web 开发人员,在一家新商店与来自桌面背景的开发人员一起工作 - 因此,他们在组织代码时具有某些特质/最佳实践 - 其中一个是将单独的 UI 视图隔离到不同的项目。

所以,在房子的网页端,我在不同的应用程序域中构建不同的项目时遇到了问题:

1) 我有一个带有 default.aspx 的“门户”项目 在后面的代码中有一个从 Login_Authenticate 事件内部调用的自定义身份验证方法,用于登录到桌面应用程序的“业务层”。业务端将会话数据存储在 ASP.NET 会话中。

2) 我有一个带有 default.aspx 的“查看器”项目 - 这最初在门户项目中作为“Viewer.aspx”,它在相同的登录方案下被覆盖并经过良好的身份验证,但我们决定它会是很好地站在它自己的项目上,因为它是一个单独的视图。

我们向两个 web.config 文件添加了相同的机器密钥,因此 .NET 表单身份验证可以通过单点登录传递。

我以两种不同的方式构建了查看器项目:

第一次尝试(它自己的 URL):

http://localhost/Viewer

第二次尝试(门户 URL 下的子域):

http://localhost/Portal/Viewer

我遇到的问题是会话没有在 Portal 项目和 Viewer 项目之间传递。我知道这是因为 IIS 在不同的应用程序域中运行它们。不幸的是,如果没有来自 Portal 的 ASP.NET 会话,查看器不会登录到业务应用程序。

是否有最佳实践/甚至可以在一个应用程序域中运行多个项目? Viewer 是否应该成为 Portal 应用程序的一部分,因为它需要相同的会话? Viewer 是否应该是一个单独的项目,需要它自己单独登录到业务层?是否有针对这种情况的最佳实践/指南?

【问题讨论】:

标签: asp.net authentication appdomain


【解决方案1】:

默认情况下会话不能在不同的应用程序之间共享。

在实践中,大多数项目都不是以这种方式分离的。以我的经验,大多数使用某种 n 层架构。基本上,您在一个 asp.net 项目中拥有所有“查看”代码,在另一个 dll 项目中拥有任何业务逻辑/数据对象,在第三个 dll 项目中拥有您的数据访问权限。然后该网站仅引用其他两个 dll。

为了解决你的问题,这个答案可能会给你你想要的:Sharing sessions across applications using the ASP.NET Session State Service

【讨论】:

  • 正确 - 这就是我遵循的方法。他们(桌面/winform 开发人员)想要的是我在一个单独的项目中构建 viewer.aspx 页面,然后通过 xcopy 将其部署到门户应用程序域。我希望为他们提供一个非常具体的理由来说明为什么这被认为是不好的做法。
  • 编程的乐趣在于你可以构建一个“糟糕”的系统,但它仍然可以工作。在你的情况下,你有一个“糟糕”的架构,但有办法让它工作。为每个视图创建一个完全不同的项目将成为维护的噩梦!我建议查看一些开源项目,看看他们是如何做到的。
  • 他们可以通过使用 xcopy 手动复制文件来部署到同一个应用程序域 - 这在他们之前手动执行的 Web 项目中得到了证明。最大的问题是我们应该——如果不是——为什么不呢?
  • 我不能给你一个“为什么不”的具体例子。框架支持它,所以很好。我可以看到相互依赖的事物没有部署在一起的示例。或者顺序不对。实际上……这是一个很好的观点。您将与可能无缘无故地以某种方式改变的事物紧密耦合。
  • 你也可以拥有一个 20 层深的继承树,“框架(和范式)支持它”,这并不意味着你应该这样做,也不意味着它“很好”。这同样适用于这里,IMO。
【解决方案2】:

有一种方法可以拥有multiple projects, but one site。这个例子有点老了,但仍然有效,这就是我们做网站的方式。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-01-08
    • 2012-11-20
    • 1970-01-01
    相关资源
    最近更新 更多