在进行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 >是一个相对庞大的工程，要完全的讲解与系统的分析还需要很多的文字。