通过本文主要向大家介绍了community server,community音箱,community,community音响官网,community是什么意思等相关知识,希望对您有所帮助,也希望大家支持linkedu.com www.linkedu.com
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是把缓存管理写在业务逻辑层中，而且缓存的数量是很大的，如对Com
在进行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是把缓存管理写在业务逻辑层中，而且缓存的数量是很大的，如对Com