目前在ASP.NET 1.1上面 可以选用的portal有两个方案 一个是starter kit 另一个是DotNetNuke(非常强大) 其他杂牌的 我就不介绍了 但ASP.NET 2.0已经想要把portal给整合进来 我用过的感觉是 好用又好维护 DotNetNuke功能虽然强大 但是要搞懂他的架构 要能够快速写出支援他的模组 我觉得是不可能在几天内上手的 下面贴一篇文章 DNN的开发小组 认为他们的产品 不可能因为ASP.NET 2.0出来後 就变的无用的论点 -------------------------------------------- Whidbey Implications on DotNetNuke With Whidbey on the near horizon it is only a matter of time before people started asking questions about its impact on DotNetNuke. What I can say is that I have had access to the Whidbey bits since the summer of 2003. I attended multiple DevLabs at Microsoft covering the Whidbey enhancements and have a very solid understanding of the new features. I am also in tune with the goals of Whidbey - one of the highest being a reduction in the total lines of code required to build an ASP.NET application. I think this is a great goal and Microsoft has constructed some good demos to demonstrate their success with this. Unfortunately, as is generally the case with demos, the simplistic use cases do not represent real world requirements. Once you get into the details a bit deeper you soon realize that there are serious limitations to the default implementations and extensibility becomes extremely complicated. One of the most highly regarded features of DotNetNuke is its multi-portal capability. You can refere to this is a "virtualization" model as it allows you to manage an unlimited number of "virtual" websites from a single shared hosted account/app/database. Well Whidbey is based on a single website per application scenario. What this means is that the DNN virtualization model is not supported by any of the new features ( ie. Membership, Roles, SiteMap, Profile, Personalization, etc... ). Because Whidbey uses a provider model, it is possible to write your own implementation for each provider - but then you are really not getting any benefit in terms of a lines of code reduction. Not to mention the APIs for many of the Whidbey providers and not extensible enough to allow for customization; therefore, you are forced to go outside the API to implement features ( which is generally not a good idea ). An interesting fact is that DNN already delivers advanced functionality in most areas when compared to the default providers in Whidbey. Since crippling the application to support Whidbey is not a viable option, we need to come up with ways to leverage the Whidbey features while still preserving our own customizations ( which in fact are our competitive advantage over other apps ). Lets look at some examples for clarity: Membership - DNN supports multiple portals where users are provided access on a portal by portal basis. Whidbey does not support this therefore we need to create a wrapper which leverages the simplistic Whidbey Membership provider and then implements our own custom business logic. Similarly, DNN has a Verified Registration option which ensures users enter a valid email address. Whidbey does not support this therefore we will need to add this to the wrapper as well. DNN has a number of user attributes ( ie. First Name, Last Name ) which do not exist in the Whidbey Membership API. These would need to be moved to the Profile provider, however the Profile provider uses a serialized object storage model which makes retrieval of attribute data more difficult ( ie. queries and reports can not be written as standard SQL statements - you need to deserialize in a business object and then retrieve the values - resulting in complicated code and a decrease in performance ). Roles - the Roles provider in Whidbey does not handle multiple portals - in fact it does not even allow the same RoleNames to be used in the same app. In DNN you can have an Admin role in PortalA and PortalB - this is not possible in Whidbey. DNN also has the concept of AutoAssigned and Public roles - this is not available in Whidbey so again, a wrapper would need to be created. DNN has a link table between Users and Roles which contains an ExpiryDate - Whidbey does not, adding yet another level of complication. The bottom line is that Whidbey provides some excellent functionality for very simplistic websites. However as soon as you want to customize your application to provide features which are not available in the default providers - you may run into complications. That being said, there are some really great enhancements in Whidbey which we want to leverage in DNN. Recently we have been focussing on the Localization implementation in Whidbey and we have been able to construct an architecture which will provide a simple migration path when Whidbey arrives. I guess to echo Nik's earlier post, we are looking at each Whidbey enhancement on a case by case basis. Our first priority will be to leverage the default implementations offered in Whidbey and at the same time come up with ways to incorporate our own advanced features ( which Whidbey does not currently support ). The next release of DNN will showcase integration of the Whidbey Membership and Profile providers in ASP.NET 1.1 ( using the exact same APIs for simple migration ). It will also showcase a Localization implementation based on the Whidbey - Implicit - Page-Level model. Based on my research and the explanations above, DotNetNuke will not be rendered obsolete by Whidbey. In fact what I predict is that DotNetNuke will actually become stronger with Whidbey and it may even influence some of the future enhancements to the ASP.NET 2.0 platform. -------------------------------------------------------------------------------- Shaun Walker Perpetual Motion Interactive Systems Inc. http://www.perpetualmotion.ca http://www.dotnetnuke.com -- http://140.109.73.177/待救的小米.mht --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.109.73.177 ※ 编辑: seagal 来自: 140.109.73.177 (10/24 02:26)