DotNetNuke和SharePoint的比较（翻译）

qqwe

DotNetNuke和SharePoint的比较（翻译）

　　原文地址是在：http://weblogs.asp.net/bsimser/archive/2006/01/31/437023.aspx
　　注：作者Bil Simser是一个加拿大的SharePoint Portal Server方面的MVP。
　　
　　术语
　　在这篇文章中我想要强调的一件事情是，虽然我将通篇使用SharePoint这个术语，但是意思可能是同时指的是SPS和WSS的功能。也请注意，这篇文章大部分都是在讨论当前版本的DotNetNuke（3.2.2和4.x）以及SharePoint（SPS 2003和WSS 2.0）。
　　
　　DotNetNuke
　　微软发布了ASP.NET，人们也看到了它的潜力，但是人们并不能完全的知道如何去使用它。我们需要使用这个新的工具去重新开发我们老的ASP程序吗？我们具体如何做？由于这个原因，任何人构建一个"门户"应用必须都自己来手工创建。每个人都需要做这个工作，我已经看到过无数次的类似行为，使用ASP或者ASP.NET完全从底层开始做起。当然，我也曾经见过类似"WebPart"这样的实现，让人们可以直接的拖到页面上。
　　到了DotNetNuke，这个令人惊讶的门户系统从IBuySpy发展而来。谈到这里，我先简短的介绍一下它的历史。微软为了展示Asp.NET的能力，曾经做了一个门户系统的示范程序，名字叫做IBuySpy，一个虚拟的网上商店系统，销售一些间谍用品，例如X光眼镜，隐藏的麦克风等等。这个应用程序有一些关键性的特点去展示ASP.NET的动态模块功能，例如通过添加"模块"到页面上创建内容，基与用户权限来控制功能的可见性，和提供一个简单的站点导航（不需要任何手工编辑页面的工作）。IBuySpy是一个起步教程，让人们可以构建他们自己的销售系统和门户系统，非常美妙。
　　2002年11月份，Shawn Walker利用这些代码创建了一个增强的VB.NET实现，名字叫做IBuySpyWorkshop。开发社区开始口吐百沫（当我们看到一个非常酷的东西时经常会这样），成千上万的人下载了这些代码。这个巨大的成功终于导致了这个项目发展出了自己的独立产品，并被改名为DotNetNuke。从那以后，一些其它的人也从IBuySpy发展出了一些自己的项目或产品，例如Rainbow等等。无论是DNN或者SharePoint都拥有许多自己独特的优点和缺点。让我们来看看他们到底有那些不同或类似，和具体的原因。
　　
　　模块（Modules） vs. WEB部件（Web Parts）
　　一个同样的东西，虽然名字不一样，但是他们仍然指的是同样的东西。DotNetNuke里面叫做模块（Modules），而SharePoint叫他们是WEB部件（WebParts），它们本质上同一个事物。由一个.NET程序集（或一组程序集）完成某个功能的业务逻辑和界面展现，并可以被放置在门户的任何地方。
　　一个SharePoint的WEB部件，就好象DNN的模块，是一个组件并且可以被使用在站点上。在DNN中，你可以添加它们到一个页面上，而在SharePoint里，你可以添加他们到WEB部件页上。以及它们提供的许多同样的概念，比如位置，个性化，最小化能力等等。DNN有一些更强大一些的功能，例如RSS订阅，自定义容器和打印能力等。而在下一版本的SharePoint中，RSS将被集成到整个系统，所以SharePoint的WEB部件也可以和DNN的一样被订阅。
　　而SharePoint最大超过DNN的好处是DNN的模块只能被使用在DNN上，而SharePoint的WEB部件则可以被使用在其它任何采用WSS作为基础开发的系统之上（Porject Server等）。这个功能实际上将会下一代的Asp.Net 采用，用Asp.Net编写的Web部件能够被同时使用在Asp.Net应用程序和SharePoint上。所以你可以说只要暴露出业务逻辑服务接口，你就可以移动模块到任何的SharePoint服务器上而不需要做修改。不过需要记得这取决于你如何编写自己的WEB部件，但是我没有见过DNN模块被使用在除了DNN以外的任何其它的系统，即使是4.x的DNN是采用Asp.Net 2.0开发的。
　　通过研究SharePoint的WEB部件，我不得不说添加一个模块到DNN简直是太方便了。基本上，你只需要打包一个模块，然后上传到一台DNN主机上，就可以在所有的门户站点中使用它了。这一切都是由系统在运行期间完成，不需要关闭系统（包括添加一些新的表到数据库中）。这点非常爽，虽然你可能会面对一些专门捣蛋的模块。而在SharePoint中这将是一个非常麻烦的工作，先添加一个程序集到BIN目录或GAC中，然后添加一个SafeControl到Web.config配置文件中，再然后，可能还需要使用一个IISRESET命令来重新启动IIS系统。假如有人编写了一个"上传WEB部件的WEB部件"将会是一个非常酷的东西。
　　我将不讨论开发一个模块和WEB部件的比较，当我深入到其中时发现所有的东西都非常类似，都是同样的概念（Asp.Net，User/Server Control等等）。
　　
　　内置模块
　　DotNetNuke提供了大概25个内置模块，他们都是不属于框架内部的，但都可以被最终用户添加到任意的页面上。在后期的版本中（3.x以上）提供了模板和向导来帮助你快速的应用一系列的页面和皮肤到你的站点上。这点和SharePoint的站点或区域模板非常类似。SharePoint提供了一套独立的列表或文档库模板，独立于采用这些模板创建的实例。
　　你可能会说DNN比SharePoint拥有更多的模块，但是你仔细研究DNN的模块后会发现，大多数DNN的模块都可以通过SharePoint的自定义列表或自定义视图配置出来。下面是一个比较详细的对照表：
　　

模块	DotNetNuke	SharePoint	备注
公告	有	有	非常类似，但是DNN提供了可以让每个公告显示时间的能力。不过WEB部件的数据视图也可以做到这点。
标题栏（Banners）	有	无	可以通过一些特殊的方法实现，但是比较麻烦
联系人	有	有	SharePoint胜出，它提供了更多的列，并且可以连接到Outlook。
讨论板	有	有	两者非常类似，平板型，并且都没太大用处。DNN拥有一个新的核心论坛模块，更加类似商业的论坛系统。
文档库	有	有	非常类似，但SharePoint提供了Office集成，版本控制，和签入/签出等功能。
事件	有	有	非常类似，都提供了列表和日历视图，重复事件，过期等等。SharePoint提供了Outlook集成，有能力为一个事件创建一个会议工作区。
常见问题	有	无	可以使用自定义列表来创建，但是需要一个数据视图WEB部件，需要Javascript编程或组视图提供展开和收缩。
反馈	有	无	SharePoint可以通过WEB部件编辑器或者自定义列表来创建，但是没有EMAIL集成。
IFrame	有	有	SharePoint是叫做页面查看器，WEB部件编辑器也可以通过一个URL来连接内容。
图象库	有	有	几乎完全一样。
连接	有	有	DNN拥有更加灵活的排序功能和表现形式，不过SharePoint也可以通过自定义方式来实现同样的功能。
新闻反馈	有	无	需要通过第三方的WEB部件，但是也可以通过XML WEB部件和XSLT文件来完成同样的功能。
用户帐号	有	有	在SPS和WSS上有不同的访问和表现形式，但是都非常类似。SharePoint使用活动目录而不是自定义列表，因此没有DNN的功能强大。
Text/HTML	有	有	SharePoint有内容编辑WEB部件，两者非常相似。
成员	有	有	DNN有更多的功能，比如最后登陆的成员，当前用户等等。SharePoint只提供了一个列表来展现一个站点的所有成员。

　　
　　这些比较并不是非常的精确，但是也非常的接近现实情况。我想说的是他们每个都有自己的优点和缺点。一个具有冒险精神的人（我不是）可能会做一个完全自定义的SharePoint模板和列表来完成标准DNN所能提供的默认功能。DNN的确有一些核心的模块是SharePoint无法提供的，但是大部分情况下，你可以通过自定义列表来提供类似的功能。
　　带上我的DNN帽子，我可以说你可以通过自定义的模块，或者需要对DNN做一些小的修改就可以提供SharePoint所有（但不是100%）类似的功能。从根本来说，一些Office 2003的集成能力也可以通过ActiveX控件来完成，所以没有人能说哪个功能必须要SharePoint来完成（例如，我曾经在一个标准的Asp.Net程序中提供过地址薄功能）。
　　唯一真正的宝石是当前SharePoint已经提供的Office集成能力，假如你大量使用微软的产品，需要处理大量的Office文档或者Outlook联系人，那么这足够强迫你使用SharePoint。否则你会花大量的时间去修改DNN，以提供Word集成能力（假如可以的话），允许Word可以签入一个文档到DNN（并不是说不可能，但是至少不是一个简单的工作）。
　　
　　可见性
　　这是一个SharePoint至今还缺乏的主要功能。在SPS中，我们可以对用户进行验证，并使用一些安全限制来隐藏某些区域。但是更多的情况是不行（特别是在WSS中），用户看到的东西多于他可以使用的。这个被叫做安全裂缝，只需要向用户显示什么事情他可以做，而不要让他通过5个步骤的向导之后，再告诉他不具有权限去完成这个过程，这会宁人感觉像是在进行一个赌博。
　　无论如何，在DNN中，我们拥有能力去分配模块的权限，或继承页面的安全设置（页面也能分配到角色）。不能分配独立的用户权限。所以你不得不定义一个角色，然后分配一个用户给这个角色，去查看（或不能查看）某个页面或模块。这种权限模型非常好，并且被大量的系统采用。只像特定的成员显示特定的信息，而在普通情况下他们将看到的是另外一个界面，直到他们登陆系统或者取得访问权限。
　　安全裂缝在下一个版本的SharePoint中仍然存在，所以DNN再一次获胜。
　　
　　自定义外观能力
　　这是一个比较棘手的比较，但是我不得不把胜利者给予DotNetNuke（至少到目前为止）。DNN使用皮肤技术来完成自定义外观，非常类似WSS的主题，或在SPS中使用自定义的CSS文件。然而，DNN的皮肤技术走得前一步，可以让你自己设计页面的布局，包括添加模块和控件（比如当前日期/时间和一个登陆控件显示哪些用户登陆或者一个注销按纽）。
　　给DNN创建一个皮肤非常简单，只需要花几分钟或几个小时（根据你创建的皮肤的复杂性而定）。一个更酷的事情是DNN可以给每个页面分配不同的皮肤（主要是因为DNN使用单一页面的程序架构）。在任何情况下，SharePoint的主题技术和DNN的皮肤技术都不是一个等级的比较，坦率的说，创建一个完全自定义的皮肤对DNN来说是一件非常容易的事情（我为我自己的站点创建一个WSS的皮肤花了我将近一个小时）。
　　当然，我也不得不谈到下一个版本的SharePoint将会完全利用到Asp.Net的母版页技术。所以，界时这个比较可能要重新定义。
　　
　　基础架构
　　在级别上，两者几乎是不能比较的，SharePoint的承载能力非常巨大（在世界范围内，微软自己内部运行的SPS拥有将近250000个站点）。而DNN主要是提供给爱好者，在某些情况下，他也可以被应用在企业的内部网络上，当然我指的并不是像IBM，波音或者国家航空航天局这样的企业。而一个小型的拥有数百个人的公司为什么不行呢？
　　然而，随着硬件能力的提升，你可以提升DNN的承载能力。但是并没有类似SharePoint所提供的企业搜索，单点登陆，或分离索引等功能，这受限制于DNN的体系架构观点。
　　DNN提供了许多Asp.Net提供的基础项。例如登陆模块。DNN提供了一个机制处理厂商广告和收费系统。DNN也提供了处理订阅的机制。你不得不自己在Asp.Net 2.0中自己构建这些功能（这并不是一项非常困难的工作，但是仍然需要"工作"）。
　　DNN最好的部分是一个标准用户可以在外部实际的进行添加/编辑/删除功能。你可以给他们一个演示，然后现场交给他们一个任务。你可以也可以在SharePoint中完成同样的工作，但是因为某些原因，大多数用户仍然摸不着头脑。也许是我总是面对一些比较笨的人吧。
　　
　　社区
　　你大概会同意DotNetNuke社区远远大于SharePoint，DNN站点被数以千计的商业站点、社区站点和个人站点运行着，而SharePoint只有数百个。这也可能是由于免费和受费的结果。
　　（后面大量篇幅谈及商业性问题，这里省略）
　　
　　总结
　　（也有大量篇幅，但是总的意思是说DNN有DNN的好处和适用情景，而SharePoint也有SharePoint的好处和适用情景。相对来说DNN更加适合外部网站，而SharePoint更加适合内部网站）。