[討論] Whidbey Implications on DotNetNuke

看板C_Sharp (C#)作者seagal (待救的小米)時間20年前 (2004/10/24 02:10)推噓2(2推 0噓 1→)

留言3則, 2人參與討論串1/2 (看更多)

目前在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)