像我这样的菜鸟一开始看到DNN时,像刘姥姥进了大观园眼睛都不够用了。找了好久才找到能“下口”的地方。虽然E文很菜,但努力读完 ~\Documentation\Public\DotNetNuke Module Developers Guide 文档后,还是感觉颇有所得。
DNN的模块结构采用的是三层构架:
l         DAL:在DNNDAL层采用了Provider结构。按我自己的理解,就是先定义一个DataProvider,里面定义好模块访问数据需要的结构的,采用了单件模式。同时它是一个反射工厂。根据不同情况继承出不同的ConcreteDataProvider。同时在web.config中定义好默认的Type字串。这样通过Instance返回默认的provider
l         BLL:在这层中。一般都有ControllerInfo两部分。Controller的作用是完成所有UI需要的于数据源相联系的功能,同时完成并提供InfoUIInfoCBOCustom Business Object)。在DNNInfo的建立是利用核心提供的CBO装配集+IdataReader利用反射直接完成的。免去了由数据库到DS再到苦力般的初始化过程。在我理解中,drcache的利用,都可以极大减少由反射引起的性能损失,而极大提高编程的舒适性和灵活性,通常可以视为很好的解决方式,不知道这种理解对不对。在涉及Sql的部分,DNN利用了Microsoft.ApplicationBlocks.Data这个装配集中的内容。一般我的解决方法是利用自己写的一个Sql类,不知道哪种更好。
l         UI主功能页继承自PortalModuleBase类。这个类也是从UserControl继承而来。我想这个大家都会很了解。一般一个全面一点的模块都会实现菜单,Edit,等很多页面。特别会拥有一个Setting类来完成页面不同的Module的设置。通过不同的ModuleID来区别。(这是我的理解,我也不知道是否是这样,希望高手门指正)DNN的核心提供了大量的功能。如logging,scheduler,search等等,可以通过这些核心提供的接口来实现。按我个人的理解。UI层完成的任务就是利用BLL层,其它模块,DNN核心功能来完成ascx的建立。
由于在家里,DNN数据库一直配置不好,msdn又没装。缺少实践练习的机会。只是通过阅读团队各前辈的blog,和DNN的文档获得的一些浅显的认识。希望各位大虾如果看了的话,能够指正,免得我深陷泥潭而不觉。