开发大型应用的正确方法
我们正在 .Net 3.5 中开发一个非常大的 Web 应用程序。 两个独立的供应商在不同领域拥有专业知识。 两家供应商都位于远程，并在同一 Web 应用程序的不同功能区域上工作。 我想知道处理 UI 开发的最佳方法是什么。
用户界面有一个主结构，其中左侧和顶部有导航链接。 单击链接将打开主区域中的页面。 各个页面将由每个供应商开发。 整个主控可由一个供应商开发。 在主布局中，我使用 iframe 在主区域中显示单个页面。
我将主应用程序部署在 IIS-Master 池上，将供应商 A 应用程序部署在 IIS-A 池上，将供应商 B 应用程序部署在 IIS-B 池上。 当用户数量较多时，IIS 池会进行负载平衡。
此外，该 Web 应用程序是基于访问的，即用户需要登录才能访问页面。 我知道我也需要在这里实现单点登录，因为涉及不同的站点。
这是一个好主意吗？ 还有其他选择吗？
回复后编辑
我也有与您回复中提到的相同的担忧。 但我想到的解决方案不仅仅是因为涉及两个供应商。 两家供应商参与其中是因为存在两个独立的功能区域，并且这两个区域都有自己的用户负载，因此它也有助于正确地平衡负载。 我正在考虑完全创建两个实施单点登录的站点。 但问题是 UI 公共部分的维护。 通用库很容易，因为可以由一个供应商开发并将 DLL 分发给其他供应商。 我们如何为 UI 层做到这一点？
We are developing a very large web application in .Net 3.5. Two separate vendors are involved having expertise in different areas. Both the vendors are located remotely and working on separate functional area of the same web application. I was wondering what is the best way to handle the development of UI.
The UI have a master structure where left side and top side have navigation links. Clicking on a link opens a page in the main area. The individual pages will be developed by each vendor. The whole master can be developed by one vendor. In the master layout I use iframes to show the individual page in main area.
I deploy the master app on a pool of IIS-Master, vendor A app on a pool of IIS-A and vendor B app on a pool of IIS-B. The pool of IIS to do the load balancing as the number of users are high.
Also this web application is access based, i.e., user need to login to access the pages. I understand I need to implement single sign-on as well here as different sites are involved.
Is this a good idea? Is there any alternative?
EDIT AFTER REPLIES
I also have the same apprehension as mentioned in your replies. But the solution I have in mind is not only because two vendors are involved. The two vendors are involved because two separate functional areas are there and both areas have its own user load so it helps in load balancing properly as well. I was thinking of completely creating two sites with single sign-on implemented. But the issue is maintenance of the common part of UI. Common library is easy as can be developed by one vendor and distribute the DLL to other vendor. How can we do this for UI layer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为什么两个开发方不能在同一个 UI 项目上工作，只要他们共享源代码控制分支的同一个实例。 当母版页开发完成后，他们都可以根据母版模板构建客户端页面而不会打扰对方吗？
Why can't both development party's work on the same UI project, as long as they are sharing the same instance of a source control branch. When the masterpages are developed, they can both build client pages against the master template without bugging the other party?
与分布式团队合作可能很困难——尤其是在大型应用程序中。 事实上，有时我们不必要地改变我们的架构，只是因为我们认为这会让开发生命周期更容易。
我个人认为版本控制、持续集成、代码审查和开放通信等软件基础知识可以很好地扩展。 我建议将此项目视为一个单一应用程序，该应用程序恰好由多个开发团队编码。 让某人负责代码集成，确保所有团队都在同一页面上，并且不要更改您的架构以适应您的团队动态。
您要问的问题是：不必要地维护多个站点和单点登录系统是否真的会更好，或者您只是建议这种方法，因为您认为隔离供应商并让他们专注于应用程序的核心领域是正确的方法是什么？
Working with distributed teams can be difficult -- especially on larger applications. In fact, sometimes we unnecessarily change our architecture simply because we think it will make the development life cycle easier.
I personally believe that software fundamentals like version control, continuous integration, code reviews and open communication scales very well. I suggest thinking of this project as a SINGLE application which happens to be coded by multiple development teams. Make someone(s) responsible for code integration, ensure that all teams are on the same page and don't change your architecture to suit your team dynamics.
The question you have to ask is: are you really better off unnecessarily maintaining multiple sites and a single signon system OR are you merely suggesting this approach because you think isolating the vendors and keeping them focused on their core area(s) of the application is the right approach?
我对您所写内容的第一印象是，可能值得重新考虑该架构。
使用 iframe，您会遇到很多问题，第一个是浏览器后退按钮的行为。
一种可能的替代方案是在主应用程序与 A 和 B 之间使用远程处理或 Web 服务，并在一个地方处理整个用户界面。 与两个不同的供应商协调一致的 UI 开发可能非常困难。
My first impression on what you wrote is that it might be worth re-considering the architecture.
With iframes you are going to run into lots of issues, the first is the behavior of browser back button.
A possible alternative might be to use remoting or web services between the master application and A and B and handle the entire user interface in one place. It might be very difficult to coordinate development of a consistent UI with two different vendors.