Community Server专题二:体系结构

Community Server专题二:体系结构

在进行CS细节分析的之前,有必要先了解CS工程(解决方案)的组成,以及组成CS工程中项目的结构,本文分为三个部分:1、工程结构 2、三层构架 3、数据库构架。

1:工程结构

按此在新窗口打开图片

CS工程主要分为4个部分

a:系统底层构架项目CommunityServerComponents、CommunityServerControls,提供给其他项目父类、接口、全局变量、CS系统设置、公用用户自定义控件、用户与权限管理业务逻辑、异常处理等。

b: CommunityServerBlogs、CommunityServerForums、CommunityServerGalleries、 CommunityServerDocuments、CommunityServerGuestBook。这些项目都是通过继承、调用全局方法等实现自己的业务逻辑并且抽象出自己的Data Provider,业务逻辑不同,但项目都是采用三层结构。

c:UI项目,这里指 CommunityServerWeb。该项目中几乎不包含逻辑代码,只是简单的Html与对运用项目中的Skin(Skin是 *.ascx文件,但没有关联相应的*.cs,大致可以这样理解:如CommunityServerBlogs 中的Skin 文件*.ascx相关联的*.cs逻辑代码在 CommunityServerBlogs项目中实现,并且不保存在与*.ascx文件相同的目录下,而是与CommunityServerBlogs中其他业务逻辑一起编译为CommunityServer.Blogs.dll)。同时UI项目中还保存了Languages文件与一些配置文件等。

d: DataProvider,目前只实现了SqlDataProvider,对SQL Server数据库进行操作。DataProvider实际上是对b 部分中实体项目数据库操作抽象的具体实现。数据操作的Provider方式带来几个好处,不关心具体实现、支持多数据库、有利于团队协作分工等。

2、三层构架

在CommunityServerBlogs、CommunityServerForums、CommunityServerGalleries等几个项目中都采用了三层构架,如下图:

按此在新窗口打开图片

业务逻辑是穿插在Contorls与Components中,在单独的一个项目中Contorls与Components体现在namespace里,下面以CommunityServerGalleries项目为例讲述一下具体项目的三层结构:

按此在新窗口打开图片

为了便于文件的管理,项目中建立了Components与Contorls文件夹分别存放名字空间为 CommunityServer.Galleries.Components与CommunityServer.Galleries.Controls。如果你是一个初学者或者对三层结构不是太了解,可能很多时候你会对三层构架感到困惑,其实这个层的概念没有绝对的划分界限,更不是用类作为最小的单位。这种划分是相对的,是一种为编写代码功能的划分。CommunityServerGalleries项目中没有直接编写对数据库的操作代码,而是使用了 Provider的方式把操作的方法进行抽象:

例:public abstract Hashtable GetGalleries(bool mergePermissions);

抽象后的代码可以和普通方法一样被业务逻辑调用,由于使用了Provider的方式,使得数据层与业务层之间是松散耦合的,可以很容易的进行数据库更换(只需要更换对抽象数据操作类的具体实现方法,而不会影响到业务逻辑层的代码)。

业务逻辑包括几个部分:CommunityServer.Galleries.Components下所有的实体类,这些实体类大多数通过继承Post、 IThread、PermissionBase等在CommunityServerComponents项目中定义过或者申明过的类与接口。 CommunityServer.Galleries命名空间下的一些类,这些类用来处理业务逻辑运行过程中的数据,同时进行缓存和过滤等操作(过滤操作是通过在CommunityServerComponents项目中的CSApplication.cs类下定义委托与事件完成的,要理解这个过程需要对 CS有一定的了解,后续我会做一个CS中委托与事件的专题)。还有一部分业务逻辑混淆在 CommunityServer.Galleries.Controls命名空间下的一些类中,他们与UI表示层较为紧密,你很难准确的定义他们是属于业务逻辑还是表现层代码。

CS中表示层中的类大致可以分为三部分,1:是需要*.ascx的直接处理用户界面或者用户输入输出的代码,这些类都间接的继承CommunityServerControls项目中的TemplatedWebControl类。2:要进行换肤就少不了使用一些辅助的类,这些类提供一些基础服务,如:找到*.cs文件对应*.ascx所在路径等。3:是不需要*.ascx的用户自定义控件,一般继承自.NET提供的 WebControls。这些类被放入Controls/Utility文件夹下面。

传统的ASP.NET Web页面设计时在建立 *.ASPx或者*.ascx都会同时建立一个同名的*.cs文件,用来实现对页面中控件的操作,页面这个时候就像一个容器。通过Codebehind页面在运行时会自动找到对应的类(这个过程如何实现没有去分析过,但是我们可以通过反射达到同样的效果,同时可以获得更高的灵活性)。CS系统中的UI就是通过反射寻找到*.ascx对应的类从而实现相应的UI处理函数,而*.ascx只要保持名称和内容中控件的ID不变,具体Html代码如何更换并不影响到整个系统的功能,CS系统也正是通过这样的手段达到换肤的目的,同时加入MasterPage又可以减少Html代码中重复部分。最后Html与CSS 样式表的结合你就可以很容易改变网站的皮肤的样式,包括文字样子和div的布局了。*.cs与*.ascx文件剥离后网站美工与程序设计人员就真正的分开了,有利于团队协作,发挥个人特长。

还有一点必须说明:在CS项目中很多*.ASPx文件只是一个加入了MasterPage的框架页,甚至是一个什么都没有的空文件(如多数default.ASPx页面),框架文件中嵌入了大量的类似于“<Galleries: GalleryAdmin id="GalleryAdmin" runat="server" />”这样的控件,其实这个控件对应于Skin- GalleryAdmin.ascx的皮肤。如果你能理解到这里,想看明白CS的大部分代码应该不会有问题。

3、数据库构架

先看一下DataProvider模型:

按此在新窗口打开图片

模型中可以看出抽象的DataProvider是与具体的数据库操作DataProvider分离的,在CS中Components与抽象的 DataProvider被编译在一个项目中,而SQL Server DataProvider则被单独的编译出来。好处都可以看到那就是更换不同的 DataProvider抽象实现不同的数据库操作,另外这种松散耦合的方式有利于团队开放。如何实现这样的DataProvider方式呢(我这里简述一些,具体的请关注后续的专题)?

先看抽象类,抽象类被存放在相应项目的Providers目录下,以Gallery项目为例子,它的命名空间是CommunityServer.Galleries.Components


按此在新窗口打开图片
整个类都是public abstract class,这个很好理解,其实关键的是在“Instance”

部分,在 Instance里通过调用CommunityServerComponents项目DataProviders.cs类中的CreateInstance方法初始化一个GalleryDataProvider。

过程是先在Communityserver.config文件中找到

public static readonly string GalleryDataProviderName = "GalleryDataProvider";

中的“GalleryDataProvider”,这里为:

<add  name = "GalleryDataProvider" type = "CommunityServer.Data.GallerySqlDataProvider, CommunityServer.SqlDataProvider" connectionStringName = "SiteSqlServer" databaseOwnerStringName = "SiteSqlServerOwner"    />

根据“type”中的内容,运用Type.GetType与Activator.CreateInstance把 CommunityServer.SqlDataProvider.dll程序集中对应的 CommunityServer.Data.GallerySqlDataProvider类实例化,实例化后类似 GalleryDataProvider.Instance().GetGalleries(true)的调用其实就是直接操作 CommunityServer.SqlDataProvider.dll程序集中 CommunityServer.Data.GallerySqlDataProvider类下的

public override Hashtable GetGalleries(bool mergePermissions)方法。这个过程可能比较难理解,但是理解只是时间问题。

数据访问层的中与数据库最紧密接触的就是SqlDataProvider(SqlDataProvider是对SQL Server数据库操作抽象的实现,你也可以对其他数据库进行抽象实现,目前CS只提供SQL Server实现),在SqlDataProvider里使用的是对存储过程的操作而没有使用 SQL Text。在前一片专题中我写过这个做的好处,这里不再多说。主要说明的是对数据的缓存与序化:

缓存:我个人习惯是把缓存写在数据层里,而CS是把缓存管理写在业务逻辑层中,而且缓存的数量是很大的,如对CommunityServerGalleries项目中的读取单个Gallery方法:

public static Gallery GetGallery(string applicationKey, bool cacheable)

一般的做法是为这个方法写一个存储过程,然后当有数据操作的时候从数据库中调用相关数据,同时根据参数是否缓存数据,这看起来很好。我也总是觉得内存宝贵,能少缓存一点就少缓存一点,但是CS的做法是把全部Gallery读入Hashtable,缓存掉!要读取单个Gallery的时候从缓存中找,根本不去管数据库,更不要写存储过程(这倒是很方便)。当然了,CS中是对缓存定义了时间的。时间到期后缓存就自动被释放了,但是在缓存释放之前新的数据是不会被显示出来的,对于一些更新不是很快的数据集来说这算是一种比较好的解决方案(在SQL 2005中有更好的缓存解决方法,可以在新数据更新时更新缓存)。

数据序化:开发过CRM的朋友应该都有体会,很多字段需要预留在数据库中,因为你不了解使用CRM系统的客户会有一些什么样的存储要求,如:CRM用户需要保存他客户的年龄,但是CRM系统设计过程中不可能为这样一个问题特意的加入这个存储字段,通常的做法是给一些空字段,用户使用的时候相应的对他进行初始化。但是导致的结果就是CRM的数据库惨不忍睹。更可怕的是,如果要进行软件升级的时候如果需要添加一些原本没有的字段,非常的麻烦,从实体类到数据库操作的存储过程都需要更改。而数据序化可以解决这个问题,其实当我第一次看到CS这种做法的时候是非常兴奋的:第一,实现了添加字段不需要重新写数据操作类,更不需要对相关的存储过程进行修改。第二,存储的字段很工整,全部值都保存在两个字段中,如图:


按此在新窗口打开图片

先分析一下存储的数据,首先是PropertyNames字段,“EnableComments:S:0:4:ModerateComments:S:4: 5:EnableRatings:S:9:4:” “EnableComments”其实是在实体类中定义的一个属性名称,“:”表示定义完毕,“S: 0:4”表示在PropertyValues字段中的字符从0开始后面4位属于“EnableComments”的属性值,同理:“S:4:5”表示,从第四个字符开始,后面5个表示“ModerateComments”的属性值,以此类推可以获得PropertyNames所有的字段的值。(记得在 ASP.NET Forums时数据的序化是用Binary存储的,在CS中改为ntext可以对其进行搜索,解决序化后的数据搜索不便的问题。),关于如何进行序化等后续专题加以叙述。

在CS的最底层就是数据库和存储过程了,关键的几个表cs_Groups、cs_Sections、 cs_Threads和cs_Posts表分别对应于CommuntyServer.Components命名空间下的Group、Section、 Thread和Post类,Groups是分组,对应论坛来说就是“板块组”、版块”、“线索”和“帖子”,对应于Blog就是“博客分组”、“博客” “线索”、“随笔或者文章”。这个cs_Threads有点难理解,其实它是对相应Section下的Post相关信息的统计与跟踪,如最后回帖时间、评论总数等等。

上面大致分析了Community Server项目的体系结构,细节部分会在后续的专题中一一的分析。不管怎么说Community Server是一个相对庞大的工程,要完全的讲解与系统的分析还需要很多的文字。

AspNet技术Community Server专题二:体系结构,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。