DotNetNuke模块和数据展示（一）

    对于标准的DotNetNuke模块，数据是和模块相关的，这个也就是我们在开发模块的数据结构的时候，比如像Survery模块等，主表必然是有一个 ModuleId这个字段的，这也就保证了当我们在同一个网站中即使有100个该模块的实例，但是其数据却是完全不同的，从而保证了我们可以在同一个网站 中对模块进行任意多次的重用，这个是非常好的一个特性。

    同时，DotNetNuke的模块机制确保了模块是一个完全封闭的、完全有自我行为控制能力的独立的小整体，就像是美利坚合众国下的州一样，虽然属于同一个体制之下，但是却可以有自己的法律和行为——这个就可以理解为模块的Control（控制）。

    以上所讲的可能有点啰嗦而且难懂，但是我却坚持要将之讲出来，是因为我觉得这对于我扩展DotNetNuke来说非常重要。

    对于DotNetNuke来说，每一个模块，就可以理解为一个完完全全的、完完整整的系统（在DotNetNuke大框架之内的完整），完全不依赖于其他任何的普通模块（管理模块除外）。

    当然，这也有一定的限制，也就是对于DotNetNuke来说，模块之间，基本上是没有互动的；而且，模块之间的数据，也是毫无关系的。而我在进行模块开 发的时候，认为如果模块之间完全没有关系的话，实际上可能不能反映某些实际的案例，所以，在我的数据结构中，就已经预留了相应的接口，从而确保模块之间（当然是同一类型的模块）有可能进行数据的共享，这也就是我在《 DotNetNuke自定义窗体模块的数据结构（二）》 的数据结构中，除了常规的ModuleId之外，还要增加FormID和KeyID的缘故，我希望的是开发出来的模块既可以做到像通常的 DotNetNuke模块那样，有本模块完全独立的数据，也可以在管理员配置的情况下，不但可以展示本模块实例的数据，同时也可以展示统一模块下其他模块 实例的数据。

    标准模式下，DotNetNuke的模块和数据之间的关系应该是如下图所示：

        经过数据结构的重新设计之后，我们的一个模块既可以对应自己本模块的数据，也可以在某种情况下，将其他模块的数据“拿出来”一起进行展示。按照我们的数据结构，DotNetNuke的模块和数据的关系就如下图所示：

    上图中，模块实例01和02仍然是只展示自己的数据；但是模块实例03则既可以展示本模块的数据，又将01、02两个模块的数据取出来一起进行展示。

    这样的好处是什么呢？我个人认为，在业务逻辑非常复杂的情况下，如果数据非要用一个模块来展示的话，可能会造成权限的 极其复杂，甚至会造成权限的混乱；而如果模块之间的数据可以共享的话，那么，复杂的业务逻辑，就可能可以拆分成若干个模块，这若干个模块每一个专注某一项 功能，和页面的权限、模块的权限组合在一起，可以较为轻松的完成在一个模块中很难完成的业务逻辑。

    嗯，仍然是有点难以理解，需要晚一点，我们会涉及到这种情况的例子，到时候我们再回来看这一章节。

转载于:https://www.cnblogs.com/dnnworkflow/archive/2008/11/03/1325799.html