集成多个ASP.NET应用程序 [英] Integrate multiple ASP.NET applications

问题描述

您好，很抱歉，如果这个问题重复，但是我不知道上一个问题在哪里.它在这里:

我被要求设计一种解决方案来集成几个ASP.NET应用程序(其中一些很大)，其中集成意味着:

-共享布局和CSS
-常见的页眉，页脚和菜单
-仅共享一个登录区域

我放弃使用一种解决方案加入应用程序，因为它们很大，并且将来可能会有更多的应用程序，所以我考虑定义一个MasterPage或Custom Control，它将包含在每个应用程序的每个页面中.

此MasterPage或自定义控件"将定义公用部分并控制访问安全性.

您如何看待该解决方案?其他(更好)的可能性?更好的是MasterPage还是自定义控件?

谢谢您.

Hello,sorry if this question is duplicate, but I don''t know where did the previous one go. Here it goes:

I''ve been asked to design a solution to integrate several ASP.NET applications, (some of them are big), where integrations means:

- Share layout and css
- Common header, footer and menu
- Share only one login area

I discard joining applications under one solution as they are big and in the future there may be more applications so I''m thinking of defining a MasterPage or Custom Control that will be included in EVERY page of every application.

This MasterPage or Custom Control will define the common parts and control the access security.

What do you think of this solution? Other (better) possibilities? What''s better, MasterPage or Custom Control?

Thank you

推荐答案

最肯定的是，您需要一种解决方案.你说，它太大了.错误的！您的任务太大；而且你不能把它缩小.通过在一个解决方案中失去它的集成，您将拥有更大的权限(由于多个解决方案而有所增加)，并且您将失去可管理性(这可能已经是一个问题).不要犯这个大错误.

我曾经在两个大型代码库中实现过一个主项目"的变体.您可以在一个主项目以MSBuild格式构建的一个集成件中拥有多种解决方案(学习此工具，掌握它非常好).从某种意义上说，这仍然是一个统一的解决方案.唯一的好处是:您一次只能打开一个较小的解决方案.不过，您更有可能只需要一种解决方案.考虑到您将消除所有重复项；每段内容/代码都应在同一段中，而不是副本中.干燥.原则(请勿重复自己，请参见 http://en.wikipedia.org/wiki/Do_not_repeat_yourself [ ^ ]).

最重要的是，您需要制定一些部署策略.您没有提到一件重要的事情:应该将它部署在多台服务器上还是合并到一台服务器中?如果仅仅是一个，是在不同虚拟主机和域/子域中的一个站点还是多个松耦合站点?如果所有内容都合并到一个更大的站点中，那么部署就没有什么特别的了，如果不是这样的话，那就有点复杂了，但这并不是将工作分解为多个解决方案的充分理由.

一个形式上无关但实际上很重要的问题是:您是否使用任何版本控制系统?我会说:甚至不要玩不使用一个的想法.您应该保护开发并从将所有内容放入单个代码数据库开始.查看此讨论:
版本控制系统，该从中选择? [ ^ ].

我认为MasterPage和Custom控件不是彼此替代的. MasterPage很好地支持一致的页眉/页脚和其他常见元素，而自定义控件是一种用于复合控件的模块化工具.当然，几乎可以肯定，几乎所有地方都需要MasterPage(因为要缩进以保持这种一致性)，并在适当的地方需要UserControl.

—SA

Most certainly you need one solution. You say, it''s too big. Wrong! Too big is your task; and you cannot make it smaller; by loosing integration of it under one solution you will have is only bigger (a bit, due to multiple solutions) plus you will loose manageability (which is probably already a problem). Do not do this big mistake.

There is a variant of a "master project" I used to implements in two big code bases. You could have multiple solutions in one integrated piece built by one master project in the format of MSBuild (learn this tool, it''s very good to master it). In a way, this is still a unified solution; the only benefit is: you can open just one smaller solution at a time. Still, it''s more likely that you need just one solution. Take into account that you''re going to get rid of all duplicates; every piece of content/code should be in one single piece, not copies. D.R.Y. principle (Do not Repeat Yourself, see http://en.wikipedia.org/wiki/Do_not_repeat_yourself[^]).

On top of that, you need to develop some deployment strategy. You did not mention one important thing: is it supposed to be deployed on multiple servers or merged into one? If just one, is it one single site or multiple loosely-coupled sites in different virtual hosts and domains/sub-domains? If everything is merged in one bigger site — there is nothing special about deployment, if not — a bit more complex, yet this is not a sufficient reason to break the work into multiple solutions.

One formally unrelated but practically important issue is this: do you use any Revision Control System? I would say: don''t even play with the idea of not using one. You should protect the development and start from putting all content in the single code data base. See this discussion:
Revision control systems, which to choose from?[^].

I don''t think MasterPage and Custom control are alternative to each other. MasterPage is good to support consistent header/footer and other common elements, and custom control is a kind of modularity tool for compound controls. You most certainly need MasterPage nearly everywhere (as you indent to have such consistency) and UserControl where it is appropriate.

—SA

感谢您的回复，我忘了补充一点，有些应用程序在VB下，而另一些在C#下，我知道它们可以共享解决方案，但是认为这是一个附加的困难，另外，不同的应用程序使用复杂的库，Web服务，其中一些使用COM库，等等.我的意思是，也许很多参考文献都应该保持分离. br/>
顺便说一下，我将使用Microsoft Team Foundaion源代码控制，您是否对他的MasterPeges解决方案感到不便?

到目前为止，我敢打赌，MasterPages解决方案并不完美，但是...

无论如何，我都会很高兴听到您的意见.

谢谢

Thank you for your resposne, I forgot to add that some applications are under VB and others under C#, I know they can share solutions, but I think it''s an added difficulty, plus, the different applications use complex libraries, web services, someof them use COM libraries, etc. I mean, maybe lot''s of references I think it would be better to keep separated.

By the way, I will use Microsoft Team Foundaion source control, do you see any inconvenience with he MasterPeges solutions?

By now I bet for the MasterPages solutions, it''s not perfect but...

Anyway I will be happy to hear your oppinions.

Thank you

这篇关于集成多个ASP.NET应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！