之前因为看有人怀疑我的DNN C#版本不是官方的，我晕，我得把整个事情的来龙去脉给写出来。
5月27号我收到DNN的Newsletter说DNN要出C#版本了，因为调查发现63%的人希望DNN有C#版本，原文如下：
Shaun first launched DotNetNuke on December 24, 2002. I don’t think it’s a stretch to suggest that the first inquiry about a C# version came in on about December 25. And they have continued to come in on a fairly regular basis igniting all sorts of “language wars” which continue to this day. Scott Wiltamuth is the Microsoft Product Unit Manager for Visual Studio Languages and recently described the co-evolution of VB and C# from his point of view.
2004 seemed to be the year of the great DotNetNuke C# debates on the ASP.Net forums, our own Bruce Hopkins finally pinned a response which we transposed to our own forum to preserve it. Basically, although we’re as interested in C# as the next developer, DotNetNuke originated in VB.Net and there’s never been a compelling enough reason to change that. However, there is no shortage of fodder for comparison on both sides of the ongoing debate. For example:
- A 2007 Forrester Research poll indicated that 59% of .Net developers use only VB.Net
- Scott Wiltamuth (cited above) indicates “the most reliable numbers we have… show roughly equal adoption” for VB.Net and C#.
- A 2008 telerik survey suggested that C# (63%) had surpassed VB.Net (34%) as the primary programming language
- And Scott Hanselman cracked me up with equating rooting for VB like rooting for the Red Sox.
I dare you to google net vb vs c# and see what kind of interesting reading you can find *grin*.
There still is not a compelling reason to change or a clear picture of advantage. Heck, there’s not even a clear consensus on what constitutes advantage. What we do know is that a lot of people have been interested in this for a long time and we now have a community member who is quite serious about helping us keep up with a C# version! And we also have a DotNetNuke Corp engineer working alongside them to keep up the momentum. Thank you Ben for your commitment and to our own Keivan Beigi for working alongside him!
One thing to note is that these package are NOT currently tested. This is where I stick in the obligatory legalese:
Use at your own risk! At present this is strictly a project for developer interest. Although the contributors are professional and conscientious, there is no official testing or validation applied to this code base or packages. We highly discourage any attempt at production usage based on this risk.
Right now, there are published packages of the C# source for version 5.4.1 and 5.4.2. The team is working on adding this packaging to our automated build process so that new packages can be created quickly once the conversion has been done. A normal turnaround should be just a few days after each regular release.
If you’d like to discuss the C# project, I’ve pinned a thread in the development forum for that purpose. I hope you’ll let us know what you think!
于是我开始下载源代码进行研究。我从毕业接触的第一个项目开始使用DNN3。
最新C#版本下载：http://dotnetnuke.codeplex.com/releases/view/47716
截图：
整体上DNN5和其它比较大的企业级应用系统一样分为web服务器和数据库服务器。Web服务器包括表现层，商业逻辑层和数据访问层，而数据库服务器主要是数据层。如下图：
首先给大家介绍下DNN的表现层，上图中的Presentation部分：
表现层主要包含如下几个部分：
- web forms : 整个DNN主要的就是哪个default.aspx页面来展示内容。它是整个系统的入口点。当某个动作发生时，它会动态的加载表现层需要显示的内容。
- 皮肤: default.aspx页面会为不同的页面加载它的皮肤。DNN皮肤更换非常灵活，这是它很大的一个优点。皮肤的基类是在DotNetNuke.UI.Skins这个命名空间。最基本的类是Skin.cs这个类，如下图：
后面的文章里我将会和大家仔细来研究皮肤这部分的代码如何来加载html皮肤文件的。
- Panes: Pane这个类是在DNN 5加进来的。一个皮肤文件可以包含很多个pane。
- 容器：每个Panel上面都会有来加载DNN模块，页面或者是portal的容器。容器的基类是在DotNetNuke.UI.Containers命名空间下，如下图：
- 模块(Module)：每个模块至少有一个用户控件(.ascx文件)。这个控件会被load在容器里面。DNN所有的模块都在文件夹DesktopModules/…下面。
- 客户端js脚本：大部分的js脚本文件都放在js文件夹下，dnn允许一些模块去包含和引用js文件。比如DNNMenu控件就用到dnnmenu.js。皮肤用的js文件就需要放在皮肤的安装目录下，自定义模块用到的js文件放在自定义模块的目录下。
下面我们来串一下DNN的表现层是如何工作的：
当客户端访问DNN的portal时,会看到default.aspx页面，default.aspx页面的后台代码default.aspx.cs文件会加载当前页面的皮肤，皮肤必须是个继承了DotNetNuke.UI.Skins.Skin这个基类的用户自定义控件。
首先皮肤这个对象会针对皮肤文件中每个文本区域创建一个Pane对象，并且把它们放在一个大的容器中。皮肤对象会迭代当前portal的所有module。接下来皮肤对象会把这些module传给适当的一个Pane来展现出来。如果一个Pane有两个或两个以上的module,那么这个pane将会生成一个大的容器来存放这些module。
接下来每个Pane将会决定该给它的module使用哪种类型的container。Pane对象为每个module初始化一个Container对象.
上面动作完成后,Container对象就开始查找是否自己的module继承了DotNetNuke.Entities.Modules.iActionable这个接口，如果是，Container将会找到继承的那些动作，并顺序的把它们放到contianer中。
皮肤,容器和模块都能有自己的css文件。在加载它们时，它们都会在自己的目录下查找是否有一个css文件，有的话就加载到客户端。
上面的过程如果你看着不是很清晰，你可以通过下面这个图解来理解：
DNN的逻辑表现层介绍
如文章开始的图示，逻辑表现层主要有如下几部分:
- Localization :也就是传说中的区域化。可以选择不同的语言。
- Caching: 通过使用缓存让页面在客户端的响应速度更快。
- Exception management: 异常处理。一个好的系统异常处理也是必须。这样可以让用户更加舒服。
- Event logging: 日志的记录。。。。
- Personalization: 个性化的设定。
- Search: 搜索
- Installation and upgrades：很好的升级和安装模式。
- Membership,roles and profile: 角色管理等。
- Security permissions: 安全许可。
所有的这些逻辑表现层的实现都是使用DNN中非常出色一个模式：CBO and CBO controller。(可能你对这个比较迷惑，没关系，我会在接下来的文章中着重介绍一下。这里你先理解大致的框架就行了)。
CBO本质上是对整个应用程序中某个对象的一个展示。
在DNN中，一个CBO是一个DotNetNuke.Service的实体。目前DNN5中所有的CBO如下:
上面开始介绍逻辑表现层包含的那几部分，我们在CBO里都可以找得到。
CBO就好比在MVC里德Model部分，它一般都会是一个只有属性的类，而对它执行操作的那个CBO control就好比MVC中的controller类。
如果这么理解的话CBO模式其实算是老模式了，但是这里比较奇特的是一个CBO Hydrator的类。它的位置：
仔细去看它的代码你会发现它的作用就是把用到的对象的属性放到缓存中，当某个对象被再次用到时，所有的属性值直接从缓存里得到，对服务器来说压力减少了。图示：
DNN的数据访问层介绍
数据访问层就是为了能够向商业逻辑层提供数据。DNN的数据访问层使用的是Provider Model模式。
Data Provider是DNN中第一个成型的Provider Model模式的实例。当初DNN只是支持SQL Server数据库，但是很多人都要求它能够支持其它的数据存储，这样就需要一个扩展性非常好的数据访问层，也就引入了Provider Model模式。如下图：
因为Provider Model能够让一些特性更加独体，不会依赖DNN的API，所以DNN大部分的CBO的数据提供都是Provider Model来进行的。主要包括如下一些Provider:
以上基本上介绍了DNN的整体架构，当然由于我的表达能力和你本身可能刚接触DNN的缘故，你会很迷惑，甚至觉得没啥用，不过我希望我接下来拆开每一部分来介绍DNN能够让你更加的了解DNN。也希望你可以去codeplex上下载DNN的C#来体验下。接下来都会是结合代码来进行的，所以建议你去下载DNN
这里再补充一下DNN的命名空间介绍：
DotNetNuke.Common: 整个应用程序中任何地方都可能用到的类的集合。
DotNetNuke.Data: 所有需要于数据库交互的地方都会用到的类的集合。
DotNetNuke.Entities: 所有显示和管理Host,Portals,TabsUsers和Modules的部分都会用到的类的集合。
DotNetNuke.FrameWork: 一些最基本的类的集合。例如Usercontrol的基类，Page的基类等
DotNetNuke.Security: 用户权限管理部分的类的集合。包括认证，以及页面的访问权限管理等。
DotNetNuke.UI：用户接口的类的集合。例如：
DotNetNuke.UI.Skins.skin,DotNetNuke.UI.Containers.Container等等。
