.....

VB, (5 yrs)
VC++, (5yrs)
COM/DCOM/COM+, (3 yrs)
.NET,(2 yrs)
.....

able to emcompass old COM code
in .NET framework is desirable....


hahaha

1.c++ is originally designed for web, it has been execlling at non-web areas, such as graph, image, real-time..., whereas .net is only for web, so if you are not in this area, don't worry.
2. VB.net vs. c#
as an old vb fan, you will find VB.net is a little more powerful than c#. believe it ot not.
3. c# Vs. java2
as a java coder, you will find out a new brother.
4. .net=c# or VB7?
it's much much more than c#+VB.net, languages are not the core.
even the out-of-date c can build up any hot web project.

5. the market is needing "developers" rather than "coders".

本文发表在 rolia.net 枫下论坛同任何新的技术一样，人们对.NET也有一些误解。让我们来看看四个最普遍的误解的真实情况吧。
by Mark Driver
涉及技术： .NET Framework, Visual Basic .NET, C#
Visual Studio .NET (VS.NET) 终于发布了，这个新平台很快在开发人员中流行开来。然而，同任何新的技术一样，人们对它也有很多担心、不确定和迟疑——这种想法甚至比其它产品的更多。在同.NET的预期采用者们进行谈论时，我发现人们对它的几个普遍的误解似乎是造成这种担心和恐慌的原因。

本月我将重点解决人们对.NET的四个最大的、最普遍的误解。它们不仅会给人们带来相当大程度的、毫无根据的担心，在某些情况下，也会让人们对.NET产生极度的狂热——这两种情况都会对成功采用.NET策略造成危害。

1. .NET 是基于 Win32 和 COM的
Microsoft的组件对象模型（COM）是Windows应用程序组件结构的核心和灵魂。过去，COM是Microsoft操作系统中编写的应用程序、组件、工具和构架的主要的互用层。如今，.NET和COM的关系使许多开发人员把他们混淆在了一起，他们错误地认为.NET是现有的COM结构的扩展和演变。换句话说，许多开发人员认为.NET是基于COM的。

实际上，.NET在很大程度上完全是一个新的软件平台和组件结构。本质上，.NET把COM归入到一个“遗留的”环境中。这当然不是说COM应用程序在一夜之间就消失了；它们在未来的几年中很可能仍然存在。但是，正像Win32/COM在很短的时间内替代了基于字符的DOS应用程序一样，这个“新产品”将为从COM到.NET的过渡提供一个起点。

在向.NET的过渡过程中，你可能会看到投入市场的新的基于COM的应用程序越来越少。渐渐地，随着时间的推移，.NET将替代基于COM的应用程序，先形成一个混合的模式，然后到2005年，对于大多数基于Microsoft的解决方案，将会形成几乎100%的纯粹的.NET应用程序。

开发人员对.NET和合称为Win32的传统的“本地”Windows编程APIs之间的关系也感到困惑。Win32描述了一系列具有各种兼容性的操作系统（OS），从现在不支持的Windows 95到Windows XP。虽然将.NET描述成是基于Win32的会稍微精确一些，但这种概念也并不完全正确。

的确，.NET构架是依赖于底层的Win32 APIs而连接到OS的。然而，典型的.NET开发人员——不同于如今的COM开发人员（尤其是C++程序员）——将很少直接暴露在底层的Win32层中。作为替代，.NET构架包含它自己的类库，这个类库既完全代替了底层的部分Win32层，又作为一个封装机制将开发人员同其它部分的细节隔离开。正像Visual Basic以前的版本将开发人员同许多Win32的低级的“plumbing”细节隔离开一样，.NET取得了更大的进展，它提供了一个完整的多语言软件平台，该平台在很大程度上完全从底层的OS隔离出来。所以，从传统意义上讲，典型的.NET开发人员绝对不是Win32开发人员。

对许多开发人员来说，他们对COM和Win32的低级的细节问题感到很苦恼，所以.NET很受他们的欢迎。对另外一些人来说，.NET的确让他们感到恐慌。正因为.NET是“新奇”的，才形成了这种“玻璃杯半空半满”的情况，我在二月份的专栏中对此做过探讨（见资源）。一方面，.NET引进了另人兴奋的和有价值的新功能；另一方面，它是以一个新的、未经考验的应用程序构架为代价的。

因为.NET构架包括一个到老的COM世界的有力的过渡，所以相继产生了另外的误解。实际上，开发人员可以将软件服务（如程序、组件、模块等等）呈现成COM组件，让.NET组件来使用。同样，开发人员可以将.NET组件呈现为标准的COM组件。

一个.NET开发人员可以完全不用COM代码来构建整个应用程序系统。他或她也可以构建“混合的.NET”解决方案，将遗留的平台同新的平台结合起来。在Gartner公司，我们认为这种混合模式将在采用.NET的最初几年内占统治地位，因为大多数开发人员在匆忙重写他们现有的COM应用程序时，发现TCO或ROI优势并不多。因此，一种“如果没有被破坏，就不要修理”的策略使人们将现有的COM服务同不断形成的.NET技术结合起来使用，这种趋势将至少持续到2004年。

.NET采用者的经验：最不会带来伤害的采用策略就是避免陷入企图将你现有的基于COM的应用程序“扩展”得太多这种陷阱。你也应该避免仅仅因为.NET很新就立即完全重写你现有的系统。对大多数企业来说，将.NET直接但渐进地灌输到一个软件开发策略中是最好的方法。采用一个进度，在未来的三到四年内慢慢地、安全地转移你对低级的COM和Win32 APIs的依赖。

2. .NET 是COM+的替代
一个“+”号带来多大的不同。虽然.NET在很大程度上是COM的替代，但它不是COM+的替代——至少现在还不是。这是一个很容易犯的错误，因为COM和COM+这两个名字很像。虽然COM是一个组件模型，但COM+是一组以中间件为中心的应用程序服务。实际上，虽然它们常一起使用，但COM+和COM在很大程度上是相互独立的。

COM+服务，如异步的消息（MSMQ）和事务处理（MTS），构成了Microsoft的中间件软件堆栈的支持功能。这些服务共同构成Microsoft DNA 结构的“应用程序服务器”层——尽管Microsoft并没有明确地用那个术语。

虽然.NET构架、组件模型和分布机制（装配）在大多数情况下代替了COM中同等的概念，但是同在它之前的COM/Win32应用程序一样，. NET应用程序仍然运用底层的COM+服务。换句话说，.NET构架没有与诸如MTS或MSMQ之类的服务等同的本地概念。确切的情况是，.NET提供了一组封装类，作为现有的COM+服务的适配器。

这就在.NET开发人员中形成了支持派和反对派两个阵营。虽然诸如ASP.NET之类的功能增强了.NET的可扩展性，但是这种可扩展性在很大程度上仍然取决于COM+ 自身的可扩展性和稳定性。不管怎样，.NET在可扩展性和稳定性方面并没有带来很大的改变。你可以把这一点作为有利于.NET的一个因素（它的底层框架是经受了考验的），或者你也可以把它作为不利于.NET的一个因素，这取决于你倾向于哪一侧市场阵营。业界人士普遍认为Microsoft技术不断扩大其使用范围，成为大企业的解决方案。这种观点的大部分是没有根据的，或者至少只有部分是正确的，它在很大程度上被竞争者们夸大了。但是，COM+ 仍然担起了这副重担，而.NET既不排斥这种误解，也不对它进行补充。

然而，一些主要领域中的早期的成果在表面上是有利于.NET的。例如，我从.NET beta版测试人员和早期采用者那儿得到的关于ASP.NET的稳定性和速度方面的报告就是很好的。由于Internet Information Services（IIS）和Active Server Pages（ASP）众所周知的不足，ASP.NET的引进就很快流行起来（见资源）。许多开发人员已经发现了直接的、强大的理由（如性能和稳定性）来尽快采用.NET构架的ASP.NET部分，而且还汇报了其相对于ASP的主要的优势。

但是，总体上说，在“首先不伤害”现有的COM+底层框架这个法令下，大多数.NET的功能目前主要集中在生产力、方便开发、一致性等等方面。因此，Microsoft的实质性的R&D力量就主要集中于让开发人员确信.NET没有给现有的COM+结构增加相当大的费用。但是.NET并没有解决当前COM+的许多不足。例如，ASP.NET仍然是IIS的扩展。这就是说，所有IIS的不足（安全性、稳定性等等）在ASP.NET应用程序中仍然存在，就如同它们在ASP系统中一样。应用程序层已经得到了极大的改进，但是底层的IIS固疾仍然存在。

你可以期望， Microsoft在2002年努力推动向.NET移植后，它下一阶段的努力将集中在增强可扩展性和性能方面。

3. 所有.NET语言都是平等创建的
.NET构架引进了很多新的、扩展的技术，它们主要针对各种下一代软件服务。在这些新功能中，支持多种语言成为与其它竞争平台——即Java——明显不同的一个功能。与让开发人员用一种开发语言的Java不同，.NET强调开发人员可以运用他们现有的技术，并把这些技术延伸到.NET中。

实际上，Java支持其它编程语言（如Jpython），但它们都没有引起人们广泛的关注。例如，虽然Python如今是一个受欢迎的Internet脚本语言，但是Jpython——基于Java的版本——只拥有很小一部分Python用户。如今，99%的Java应用程序都是用Java语言编写的。

另一方面，.NET强调了其运用现有的技术集合和编程语言的能力，如Visual Basic、Perl、C++、甚至Java。实际上，许多其它的.NET编译器已经开始出现了，从不知名的编译器（Scheme.NET）到确实无名的编译器（SML.NET）。

不幸的是， 理想的语言“公平竞争环境”只能是种理想。事实离这种承诺相差很远。一些语言比另外一些语言更适合.NET，在.NET中尽量运用更多这样的语言就像努力把一个正方形的木桩放到一个圆的洞中一样。这并不是说这种概念没有价值；无疑它是有价值的。但是开发人员在实现这种理想前，他们必须对这种承诺采取保留态度。例如，许多编程语言必须被改进，以使它们符合.NET的普通数据类型和运行环境。在一些语言中已经做了重大的折衷，如Perl、Smalltalk和其它语言。例如，ActiveState的Visual Perl和Visual Python不生成.NET本地代码；作为替代，它们将封装类用于传统的运行环境。正如Java的宣传语“一次编写，随处运行”一样，它从来没有把这种市场宣传变成事实，随着时间的推移， 作为“语言公平竞争环境”的.NET将同样证明，这种说法更多是一种市场宣传，而不是事实。

事实就是只有少量的语言可以支配.NET的开发。在Gartner，我们认为直到2005年，VB和C# 将支配至少80%的基于.NET的开发。所以，虽然的确你可以将Pascal或COBOL编译器用于.NET，大多数开发人员对此并不关心。

4. C# 将毁掉 Visual Basic
对.NET编程语言的争论导致了关于.NET的最后一个误解。许多开发人员认为C#将压倒Visual Basic（也许甚至毁灭它）成为.NET的首选语言。这种观点的形成有许多因素。正如我在以前的文章中谈论的那样，VB.NET不是你的父辈用过的Visual Basic（见资源）。它对Visual Basic做了很多改进，使它充分与.NET平台结合在一起。一些人认为从VB6移植到VB.NET大概就相当于移植到C#。不要相信他们这种说法。

的确，说得婉转些，VB.NET和C#都需要开发人员了解底层的.NET构架的结构及其重要的学习曲线。 这个学习曲线对于所有的.NET语言都是类似的。然而，这并不是从VB转到C#的一个强大的理由。实际上，VB程序员转到C#来利用.NET构架中的功能并没有什么强大的技术原因。

作为 C家族的编程语言，C#有一定的优势，所以，对现在的C、C++和Java开发人员来说，C#更吸引人。但是VB.NET，虽然在很多方面都不同于VB6，它仍然保留VB 4GL的语法，并且是拥有全世界50%开发人员市场的一个编程工具“中心”。在Gartner，我们预计，从VB6移植到VB.NET将平均花费VB程序员约四个月的时间（取决于开发人员的情况），而从VB6移植到C#将花费约六个月的时间。这个时间段包括正式的培训，以及“实战”训练，以便熟练使用新的语言和构架。在这两种情况下，大部分时间都用来学习新的构架。在大多数情况下，从VB移植到C#只是增加了更多的变量，而没有带来重大的回报。

这并不是说C#不成功。的确，Gartner公司预计，当Visual C++开发人员采用.NET时，大部分人会积极地移植到C#。而且，第一次移植到.NET的许多开发人员将选择这种“本地”.NET编程语言作为他们主要的工具。

.NET 很新：在它今后的几个月、几年内的发展过程中，你应该预料到会碰到一些误解和错误的设想。开发人员必须将他们的期望建立在根本的事实基础上，在运用.NET的“新功能”和运用“没有被破坏的”现有的COM构架和VB语言之间进行权衡对比。

关于作者:
Mark Driver是IT行业研究公司Gartner的研究室主管，他主要进行用于分布式Internet和移动电子商务解决方案的应用程序开发策略、工具和技术的研究。他的e-mail是：dotnet@fawcette.com。更多精彩文章及讨论，请光临枫下论坛 rolia.net

本文发表在 rolia.net 枫下论坛by Lyn Robison
涉及技术： Visual Studio .NET (VS.NET), .NET Enterprise Server, .NET Framework
只有Web application server可以解决某些商业问题，但直到最近，这些强大的服务器只能用于J2EE世界。在本文中，我将讲述如何通过运用.NET Framework、Visual Studio .NET和.NET Enterprise Servers，使.NET拥有工业强度的Web application server的功能。作为例子，我将阐明如何用一个Web application server来解决一个棘手的问题：公布产品的价格，使企业可以将他们的产品卖给其它的企业。你将了解到，通过运用.NET工具，如何创建一个企业外部网的门户网站。

可以让你管理应用程序功能和数据的工业强度的Web application server有几个独特的功能。它需要包含一个运行时间，比如.NET公共语言运行库（CLR）或Java虚拟机（VM），用来执行服务器端的对象代码。它也需要一个事务管理器，比如Microsoft Transaction Server（MTS）或COM+；一个门户网站；和一个站点使用分析和报告引擎。Web application server也集成了一个关系数据库服务器、一套企业应用程序集成（EAI）工具、一个用来部署Web services的平台、一套带有一个集成开发环境（IDE）的开发工具，开发人员可以运用这些工具，根据需要来扩展系统。

理想的Web application server还应该包含一个支持分类法和元数据的内容管理系统、全文本搜索功能、具有存入(checkin)和检出(checkout)功能的文件库、一个工作流引擎、一个可以发送信息的电子邮件通知引擎、一个带有用户化产品并为每个用户提供特殊价格的产品目录、和一个你可以用于可扩展的关系管理（XRM）应用程序的用户数据库。市场上没有能够实现该清单上全部功能的J2EE application server；同样地，.NET也实现了基本的功能，但并没有实现所有更高级的功能（见表1）。

.NET的确使你不用很大的投资就可以进入application server的世界。Application server并不像你期望的那样流行，因为J2EE application server初期常需要很多钱和时间（见工具条“在J2EE和.NET之间进行选择”）。.NET可以让你最初的投资很小。你可以很容易地承担一项小范围的项目，其软件许可和开发成本很低。然后，在成功完成一个小项目后，你可以尝试一些更大的项目（见工具条“构建还是购买”）。
使你的门户成为一个企业外部网
某些商业应用程序需要Web application servers。例如，你可能需要“网络化”你们公司的信息系统、为你的战略用户创建在线式门控社团(gated community)、实施XRM应用程序或为某些用户公布特殊的价格。

网络化你公司的信息系统意味着在运行你的业务的内部应用程序上放置一个浏览器前端，它提供了以下几个优点。你可以集成独立的系统、不需要重写这些独立的应用程序就可以将它们结合起来、延长现有应用程序的寿命并提高它们的价值、使很远办公室里的雇员可以运用内部的应用程序、也可以选择性地使战略用户运用内部应用程序。通过创建企业自己私有的门户网站，将内部程序放到这个网站，企业就可以网络化他们内部的应用程序。运用一个Web application server就可以最好地实现并实施这样的门户网站。

用户总是不断期望他们的产品价格更便宜、服务更好、交付更快而且能够即时访问信息。如果一个竞争者在不断实现用户这些期望的方面做的要比你好，那么你的用户就不再是你的了。为了实现你的用户的这些期望，你可以将你的门户网站做成一个企业外部站点，这样你的用户就总是可以最好地运用这个站点了。

在你的企业外部站点上，你的用户可以注册到一个门控社团中，在这里，他们可以享受他们渴望的更便宜的产品、更好的服务、更快的交付和即时访问信息。你可以用每个用户社团的颜色和logo动态地标识你的企业外部站点上的页面，这个站点可以包含为他们定制的内容和功能。你的企业外部网站看上去将会像是你的最佳用户自己的企业内部网的一部分，这就自然使这些用户可以容易地与你进行更多的业务。要构建一个企业外部站点，使它的外表、内容和功能可以根据其访问者进行改变，这就需要Web application server的功能。

你必须为你的内部系统开发一个安全的Web接口以使用户参预你的业务。这就是典型的XRM应用程序构建的方法。与传统的用户关系管理（CRM）应用程序相比，XRM应用程序关注的重点不同。CRM应用程序用来使用户服务更有效，可以让销售人员更快地结束交易。

CRM可以使你给你的雇员授权，使他们更好的访问用户数据，同时希望你的雇员可以用那些数据更好地为用户服务。运用XRM，你可以让你的用户为自己服务，在他们需要的时候，参预你的业务。运用一个XRM系统，公司就不仅需要更好地跟踪它的用户数据，它还需要（安全地）为它的用户敞开企业防火墙。运用XRM，你可以授权给你的最佳用户，使他们可以访问你的应用程序，你也可以给你的用户提供实时、自助式报价、目录查询和在线产品配置。在联合项目、定制产品和共享的商业进程方面，你也可以同你的战略用户合作。
推动B2B交换
XRM的另一个方面是关于企业间在线商务的。许多企业将他们的产品在线卖给其它的企业。根据最近的一项调查报告，所有的电子商务中94%都是B2B商务（见资源）。除了突出的Amazon.com和其它的在线零售商外，零售方式的B2C商务只有6%，只占电子商务的一个小部分。大多数B2B商务不是在B2B市场中进行的。作为替代，它主要在有长久关系的公司之间进行，正如调查报告所证明的，三分之二的B2B商务是通过电子数据交换（EDI）进行的。

现在，你已经了解了对有效的B2B信息交换的需求，我将用一个例子向你阐明如何用Web application servers来推动这种需求。在任何企业中，当一个用户询问一个产品的当前价格时，你都需要立即作出回答。如果用户在查找价格时有困难，那么他们就不太可能购买你的产品。然而，在B2B世界中公布价格的过程通常会有问题，因为各个企业中的价格是不统一的。价格主要是建立在相互关系、协商合同、折扣等等基础上的。因此，对于每个用户，企业通常有个性化的价格。显然，单一的价格清单是不适合的。

价格也是保密的。通常，你不希望用户A看到用户B的价格。因此，以一种公开的方式来公布价格是不可行的，比如通过一个公开的网站。另外一个问题是价格通常是随时间而波动的。价格可能变化得太频繁，以至于不能以一种静态的方式来准确地公布它们，比如通过印刷目录和价格表。


图1. 在企业外部网上实施一个价格公布应用程序
实现一个B2B价格公布应用程序需要Web application server的功能。.NET没有提供一个完整的、预装的Web application server。然而，通过将.NET Framework、VS.NET和.NET Enterprise Servers结合起来，你就可以得到Web application server中的许多功能（见图1）。在实现一个价格公布应用程序时，你需要某些.NET部件，它们可以用来实现应用程序特定的需要。记住价格公布程序需要立即给用户提供一个产品的价格。它也需要为每个用户公布特殊的价格，避免用户互相看到他人的价格，而且需要动态地公布价格，这样就可以反映任何最近的价格变化。

部署一个可以公布产品信息和价格的企业外部站点是实现这些需求的一个好方法。该站点很容易访问，它可以给用户立即提供产品定价信息。企业外部站点可以接触公司的内部信息系统，从而获得、计算或查找每个用户对每个产品的特殊价格。它可以用一个注册机制来帮助鉴定和授权用户，这就避免了用户相互看到他人的价格，而且它可以公布由企业内部应用程序动态存储或计算的价格，这样价格就总是正确的、最新的。

虽然.NET没有提供一个现成的（off-the shelf)企业外部网站，但它的确提供了一套好的工具和模块来构建一个企业外部网站。ASP.NET就是一个很好的用于构建企业外部网的平台，它比以前的运用ASP和COM的Windows Distributed Internet Applications（DNA）平台要好很多。不同于ASP和COM，ASP.NET提供了一个真正的面向对象的开发平台，它使开发人员可以更容易地将显示同逻辑分离开，极大地简化了站点的开发和维护。开发人员也可以通过继承运用现有的ASP.NET对象的丰富的功能。

实现一个门户UI
门户用户界面（UI）可能是实现企业外部网的最好的方法。在艺术级的门户站点上，浏览器窗口中的“房地产”被分成包含特殊内容或功能的象限或区域。你可以在诸如My Yahoo!和My MSN的公有门户上看到这种类型的UI。

实现门户UI上的每个区域或象限的代码是从门户代码自身中分离出来的。换句话说，门户站点被建成一个框架，在这个框架中，这些一块块的UI代码被执行。这些代码块有许多不同的名字，包括portlets、gadgets、components、和modules。

在J2EE世界中，人们正努力将portlet代码标准化，使portlets可以互换，这样任何支持标准的供应商提供的portlets就可以在一个门户站点上运行了（见资源）。在.NET平台上，ASP.NET在用户控件中提供了类似于portlets或gadgets的功能。用户控件不支持portlet标准，但是它们的确将强大的面向对象的原则引入到Web页面的构建中。Microsoft在一个称为IbuySpy的基于ASP.NET的门户站点中提供了一个例子来阐明这一点，开发人员可以将这个站点作为如何构建门户站点的一个指南（见资源）。

为了公布价格，你需要实现为每个用户计算或查找正确价格的商业逻辑。你可以用VS.NET和你选择的.NET编程语言写代码来完成这一点。你将代码写到适当的用户控件中，这样信息就可以显示在你的门户UI中了。

你需要确定将哪些工具用于后端集成来得到你需要的价格数据。.NET提供了ActiveX Data Objects .NET（ADO.NET），它在关系数据库中或在OLE DB和ODBC数据源中。对于深层的集成，Microsoft提供了BizTalk Server，它运用XML提供了复杂的数据转换和应用程序集成工具。如果你可以从一个后端系统得到任何一种预期的输出内容，BizTalk Server可以让你很容易地将输出内容转换成你可以用于你的门户站点的信息。

ADO.NET和BizTalk Server可以让你从你的后端系统得到定价数据，你可以用ASP.NET用户控件和你喜欢的.NET编程语言将价格数据公布到一个门户网站上。现在你需要确定只有你认为恰当的人才能看到那个信息。
你必须扩展.NET的本地的基于角色的安全性，使其可以用于一个B2B 企业外部网环境。例如，如果一个用户是以“采购代理”的角色注册的，你就不能确定那个采购代理是为哪个公司工作的。在一个价格公布应用程序中，你只想将用户A的价格显示给来自A公司的采购代理，将用户B的价格只显示给B公司的采购代理。

为了看到用户A的价格，一个用户必须是A公司采购代理的角色，而且必须是A公司的雇员。这就需要将逻辑AND用于这些用户的特性。不幸的是，对于.NET Framework的基于角色的安全性，没有机制可以在角色上执行逻辑AND。给一个用户分配两个角色（“采购代理”和“A公司的雇员”）也不行，因为分配两个角色只能让用户有权访问采购代理或A公司雇员可以访问的任何资源。给一个用户分配多个角色，其效果同在那些角色之间运用逻辑OR是一样的。

运用基于概要（profile-based)的安全性
对于一个价格公布应用程序，你需要基于概要的安全性来确保价格只呈现给恰当的人。运用基于概要的安全性，每个用户的多个特性，如身份、雇主、角色、头发颜色、政党等等，就可以用逻辑AND和逻辑OR结合起来，这样你的企业外部站点上的每块内容和每个功能就可以得到恰当的安全性了。

.NET没有提供基于概要的安全性；你必须构建或购买。幸运的是，.NET Framework是可以高度扩展的，你不用费什么力气就可以将基于概要的安全性装到你的.NET 应用程序中。运用一个关系数据库服务器可以最好地实现该安全性，这个关系数据库服务器包含一个用户及其特性的数据库。该数据库也可以包含用来控制对企业外部站点的内容和功能进行访问的安全信息。

将所有这些信息存在一个关系数据库中，你就可以写SQL存储过程，确定一个特殊的用户是否有权访问一个特定的资源。数据库可以很容易地返回一个特定用户被授权的所有资源的清单。你可以用ASP.NET内在的User对象将这个资源清单缓存起来，使企业外部站点必须执行的频繁的授权检查的性能达到最佳。

将用户信息存在一个关系数据库服务器中也提供了另外一个好处。你可以扩展这个数据库用于XRM应用程序开发。数据库不仅可以跟踪用户的安全性，它也可以通过恰当的站点使用数据，记录用户的商业问题、管理联合项目和工作流、分析每个用户是如何运用你的企业外部站点的。

为了公布价格，你的企业外部站点也需要对产品信息进行内容管理和编目录。公司提供和出售的产品是由一长串部件组成的，这些部件以许多种方式进行配置和定制来满足用户的特殊需求。然而，如今的在线目录系统只用一个简单的价格清单出售完成的产品。

Microsoft Commerce Server主要针对小规模的零售B2C商务，你需要扩展它，使其可以用于更普遍的B2B环境，在这个环境中，产品更复杂，定价不统一，用户的支付方式是通过交换定购单和发票完成的，而不是用信用卡。

如今产品的复杂性也要求你将在线产品目录同一个文件管理系统结合起来。你在显示目录中的每个产品时，需要在它的旁边用超链接将其连接到相关的文件。这样，你就可以用复杂的信息来补充目录中的每个产品了，比如用白皮书、规范、使用指南、文件列表、产品文件等等。文件管理系统可以使公司的域专家很容易地管理那些文件。

构建文件库
从其名称上看，Microsoft Content Management Server（CMS）给人的印象是它在内容管理方面很有用。然而，CMS只能让你为一个网站创建一个设计模板，然后把内容插到那个模板中。例如，如果你在线发布一个报纸，那么CMS会很有用，因为格式是不变的，只需要经常改变内容就行了。但是它不适用于包含复杂产品的B2B目录。

Microsoft SharePoint Portal Server（SPS）是另一个产品，它的名字听起来很有希望，但是它不适用于B2B价格公布应用程序。SPS是一个用于Microsoft Office应用程序的服务器。Office 用户可以将他们的文件保存在SPS中，而不用保存在他们的本地硬盘上，这就使公司内部的其它Office用户可以很容易地访问这些文件。SPS不适用于价格公布应用程序，而且它也还没用于.NET。
因此，运用.NET，你必须为任何价格公布类型的应用程序构建目录和文件管理系统。对于产品目录来说，你也许可以扩展Commerce Server。对一个文件库来说，你可以用文件系统、Microsoft Exchange或Microsoft SQL Server。在这些选项中，我建议使用SQL Server，因为它是一个事务处理数据库，能够存储二进位的大的对象（blobs）以及元数据。很容易搜索基于SQL Server的内容库，用来存储和检索数据的编程接口很强大，有许多文件可以证明这一点。在SQL Server中实现一个文件库不是一项琐碎的工作，但它也不是一项很浩大的任务。

一旦你拥有了一个具有基于概要的安全性、后端系统集成、内容管理系统和目录系统的企业外部站点，你就可以实施你的价格公布应用程序了。我建议开始时，只实现一部分。这种想法是为了让应用程序的功能部分运转及实施起来，使你对.NET有一些体验。

最好开始时只实现具有基于概要的安全性和一些简单的后端集成的门户站点。例如，站点可以公布不包括产品信息的、个性化的、简单的价格清单。一旦你实现了这个功能，你将会得到一些经验，就可以做好准备继续开发文件管理和/或目录系统了。你也许也想在企业外部站点上实现Web services或电子邮件通知。对于这种复杂的应用程序部分，.NET可以让你每次呈现一点点，使你在严格控制时间和金钱的投资的前提下，能够逐步进入Web application servers的多方面领域。

关于作者:
Lyn Robison是Implementing B2B Commerce with .NET: A Guide for Programmers and Technical Managers (Addison Wesley Professional, 2001)一书的作者。他的第一本书是Teach Yourself Database Programming with Visual C++ 6 in 21 Days (Sams, 1998)。联系方式：Lyn@howtob2b.com。更多精彩文章及讨论，请光临枫下论坛 rolia.net