I was surprised that my dnn C # version was not official. I had to write the entire story.
In May 27, I received dnn's newsletter saying that dnn is coming out of the C # version, because the survey found that 63% of people wanted dnn to have the C # version. The original Article is as follows:
Shaun first launched dotnetnuke on December 24,200 2. 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 versions 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 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 authorization age 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 abve) 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 shoshould be just a few days after each regular release.
If you 'd like to discuss the C # project, I 'd pinned a thread in the development forum for that purpose. I hope you'll let us know what you think!
So I started to download the source code for research. I started using dnn3 from the first project I graduated from.
Latest C # Version Download: http://dotnetnuke.codeplex.com/releases/view/47716
:
In general, dnn5 is divided into web servers and database servers like other large enterprise-level application systems. The Web server includes the presentation layer, business logic layer, and data access layer, while the database server is mainly the data layer. For example:
First, we will introduce the dnn presentation layer, in the presentation section:
The presentation layer consists of the following parts:
- Web forms: the main dnn page is default. aspx to display the content. It is the entry point of the entire system. When an action occurs, it dynamically loads the content to be displayed in the presentation layer.
- Skin: The default. aspx page loads its skin for different pages. Dnn skin replacement is flexible, which is a great advantage. The base class of the skin is in the namespace dotnetnuke. UI. skins. The most basic class is skin. CS, such:
In the subsequent articles, I will take a closer look at how the skin code loads HTML skin files.
- Panes: the pane class is added in dnn 5. A skin file can contain multiple pane.
- Container: The dnn module, page, or portal container is loaded on each panel. The container base class is in the dotnetnuke. UI. Containers namespace, for example:
- Module: Each module has at least one user control (. ascx file ). This control will be loaded in the container. All dnn modules are in the folder named topmodules /... Below.
- Client JS Script: Most JS script files are stored in the JS folder. dnn allows some modules to include and reference JS files. For example, the dnnmenu control uses dnnmenu. js. The JS files used by the skin need to be placed under the installation directory of the skin, and the JS files used by the custom module should be placed under the directory of the custom module.
The following describes how the dnn performance Layer works:
When the client accesses the dnn portal, default is displayed. ASPX page, default. the background code of the ASPX page is default. aspx. the CS file will load the skin of the current page, and the skin must inherit dotnetnuke. UI. skins. skin is a user-defined control of the base class.
First, the skin object will create a pane object for each text area in the skin file and put them in a large container. The skin object iterates all modules of the current portal. Next, the skin object will pass these modules to the appropriate pane for display. If a pane has two or more modules, this pane generates a large container to store these modules.
Next, each pane will decide which type of iner should be used for its module. The pane object initializes a container object for each module.
After the preceding action is completed, the container object starts to find whether its module inherits dotnetnuke. entities. modules. iactionable interface. If yes, the container will find the inherited actions and put them in the contianer in sequence.
Skins, containers, and modules can all have their own CSS files. When loading them, they will find whether there is a CSS file in their own directory, and load it to the client.
If the process above is not very clear, you can understand it through the following illustration:
Introduction to the logic presentation layer of dnn
As shown in the illustration at the beginning of the article, the logical presentation layer mainly includes the following parts:
- Localization: that is, the legendary regionalization. You can select different languages.
- Caching: Uses cache to accelerate the response of pages on the client.
- Exception management: exception handling. A good system exception handling is also required. This will make users more comfortable.
- Event logging: logging ....
- PERSONALIZATION: personalized settings.
- Search: Search
- Installation and upgrades: Good upgrade and installation modes.
- Membership, roles and profile: role management.
- Security permissions: security license.
All the implementations of these logical presentation layers use a very good dnn mode: CBO and CBO controller. (Maybe you are confused about this. It doesn't matter. I will introduce it in the next article. Here you can understand the general framework first ).
CBO is essentially a display of an object in the entire application.
In dnn, a CBO is a dotnetnuke. service entity. All CBO in dnn5 are as follows:
The above section describes the parts contained in the logical presentation layer, which can be found in CBO.
CBO is like the MVC Reed model. It is generally a property-only class, And the CBO control that executes operations on it is like the Controller class in MVC.
If you understand this, the CBO mode is actually the old mode, but here it is a strange class of CBO hydrator. Its location:
Take a closer look at its code and you will find that its function is to put the attributes of the used objects in the cache. when an object is used again, all the attribute values are directly obtained from the cache, the pressure on the server is reduced. Figure:
Dnn data access layer Introduction
The data access layer provides data to the business logic layer. The data access layer of dnn uses the Provider Model mode.
Data Provider is the first Provider Model instance in dnn. At the beginning, dnn only supported SQL Server databases, but many people demanded that dnn support other data storage. In this way, a highly scalable data access layer is required, and the Provider Model mode is introduced. For example:
Because provider model makes some features more specific and does not rely on dnn APIs, most of the data provided by dnn CBO is provided by provider model. It mainly includes the following providers:
The above basically introduces the overall architecture of dnn. Of course, you may be confused and even feel useless because of my expressive ability and your recent access to dnn, however, I hope that I will split each part to introduce dnn so that you can better understand dnn. I also hope you can download the C # Of dnn on codeplex to try it out. The following code is used together, so we recommend that you download dnn. 5.4.4 C # version.
Here we will introduce the dnn namespace:
Dotnetnuke. Common: a set of classes that can be used anywhere in the application.
Dotnetnuke. Data: a collection of classes used in all areas where database interaction is required.
Dotnetnuke. Entities: a set of classes used for displaying and managing host, portals, tabsusers, and modules.
Dotnetnuke. framework: a collection of some of the most basic classes. For example, the base class of usercontrol and the base class of page.
Dotnetnuke. Security: a set of classes in the user permission management section. This includes authentication and page access permission management.
Dotnetnuke. UI: a collection of user interface classes. For example:
Dotnetnuke. UI. Skins. Skin, dotnetnuke. UI. containers. container, and so on.