正确开发大型应用程序的方法

Question

我们正在.Net 3.5中开发一个非常大的Web应用程序。两个独立的供应商参与了不同领域的专业知识。两个供应商都位于远程位置，并在同一Web应用程序的单独功能区域上工作。我想知道处理UI开发的最佳方法是什么。

UI具有主结构，其中左侧和顶侧具有导航链接。单击链接可在主区域中打开页面。各个供应商将开发各个页面。整个主人可以由一个供应商开发。在主布局中，我使用iframe来显示主区域中的单个页面。

我在一个IIS-Master池，一个IIS-A池上的供应商A应用程序和IIS-B池上的供应商B应用程序上部署主应用程序。用于负载平衡的IIS池，因为用户数量很高。

此Web应用程序也是基于访问的，即用户需要登录才能访问页面。我知道我需要实现单点登录，因为涉及到不同的网站。

这是个好主意吗？还有其他选择吗？

---

回复后编辑

我也有同样的疑虑，如你的回复中提到的那样。但我想到的解决方案不仅仅是因为涉及两家供应商。这两个供应商都参与其中，因为有两个独立的功能区域，并且这两个区域都有自己的用户负载，因此它也有助于正确地进行负载平衡。我正在考虑完全创建两个实现单点登录的站点。但问题是维护UI的共同部分。公共库很容易，因为可以由一个供应商开发并将DLL分发给其他供应商。我们如何为UI层执行此操作？

Answer 1

使用分布式团队可能很困难 - 尤其是在较大的应用程序上。实际上，有时我们会不必要地改变我们的架构，因为我们认为它会使开发生命周期变得更容易。

我个人认为，版本控制，持续集成，代码审查和开放式沟通等软件基础非常好。我建议将这个项目视为一个单一的应用程序，恰好由多个开发团队编写。让某人负责代码集成，确保所有团队都在同一页面上，不要改变您的架构以适应您的团队动态。

你必须要问的问题是：你最好不必要地维护多个站点和一个单点登录系统吗？或者你只是建议这种方法，因为你认为隔离供应商并让他们专注于他们的核心领域申请是正确的方法吗？

Answer 2

我对你所写内容的第一印象是，可能值得重新考虑这个架构。

使用iframe会遇到很多问题，首先是浏览器后退按钮的行为。

可能的替代方案可能是在主应用程序与A和B之间使用远程处理或Web服务，并在一个位置处理整个用户界面。协调开发一致的UI与两个不同的供应商可能非常困难。

Answer 3

为什么开发方都不能在同一个UI项目上工作，只要它们共享源控制分支的同一个实例。开发主页时，他们可以针对主模板构建客户端页面而不会引起另一方的争吵吗？