.Not，记录任何数据的“记事本”。
.Not是我最早构思出来的架构的雏形，被设想成一个可以记录一切的“记事本”。把“Note”一词最后的“e”去掉，前面加上一个点，就成了“.Not”，与“.Net”相得益彰，很有趣。
这个架构的设计起始于我的第一个商业项目结束后，在架构上吃了大堑的我，对架构设计产生了浓厚情趣，学习了大量这方面的资料，了解了ComponentModel命名空间下提供的组件和模型自描述能力。从PropertyGrid的工作方式上获得了很大的启发。
原来操作、人机交互界面的代码可以如此的简单，只要放置一个PropertyGrid控件就足够了。软件是如何工作的，可以在模型、实体上进行自描述，或者界面后面的控制层上控制。
经过学习后，我可以把软件的所有操作、特征都在界面层之后的模型层上描述完成，也就可以让开发人员更加关注到模型的设计、开发上来。我想，我可以在这种架构模式上，开发出按照人对事物的认识，记录丰富的数据信息的应用产品，我把这叫做“社会信息化”。
这种设计下的开发模式很自然地分出视图、模型和控制三层，后来我在书店偶然阅读了一本印刷精美的Structs的书，发现里面描述的MVC分层开发模式，和我的构思如出一辙，看来我的设计思路还是很合主流的。
紧接着我在北京参加在线社区的开发工作时，就推行了这种架构设计。
xbb，Extensible Bulletin Boards，可扩展电子布告板。
时间过得很快，转眼已经是07年底，当时Web2.0概念已经深入人心，博客、维基、图片、视频共享等新型应用都已经受到市场肯定，但是在我眼里看来，这些应用其实都是电子布告牌系统的扩展和演变，他们都具有“布告牌”系统的特点，就是大家都分享、传播自己的信息。所以我构思了这个可扩展电子布告牌系统，意在开发一个通用的社区应用开发架构，在其上可以支持从论坛到Web2.0应用再到未来可能出现的其他新型的社区性扩展应用。
.Not的架构设想主要集中在模型（实体）层上，他离一个完整的应用开发架构，还需要补充一些明确的设计：
.Not中让业务模型（实体）具有完善的自描述性，使他们和PropertyGrid可以完善的搭配工作，整个软件系统的所有功能都可以在一个PropertyGrid中完成控制，尽管如此，PropertyGrid的操作风格恐怕只有专业人员才会有耐心去适应，要达到日常应用的要求，必须开发能像PropertyGrid一样智能化，又能符合可用性要求的界面层。
.Not也需要一个能同样智能化工作的持久层。
xbb继承了.Not的设计，把模型（实体）和模型的自描述作为整个系统职能的中心，又完成了一组高可用性的界面控件：
一个数据操作控件，可以在一个界面上完成浏览、编辑、增删、多条件筛选、统计和多选删除等所有常用功能。
一个网站地图控件，能以多级菜单形式定位、导航用户在整个应用中的位置。
一些辅助控件，例如让多个列表联动，让多个列表中只有一项可以被选定，并共同控制、显示在一个展示区中的控件，增强了丰富的交互体验。
这些控件都使用了ASP.NET AJAX技术达到了无刷新的使用体验，并且通过CSS Friendly Adapters、ASP.NET控件重写，以及.NET 3.5新提供的ListView控件等方式，达到了完美的流布局支持，形成了一套完善的结构化HTML标记标准，可以满足复杂的流布局排版需要。
xbb会根据模型（实体）的自描述来控制界面控件和LINQ数据访问控件如何工作，从而达到了一个高智能化的快速开发框架。xbb也对界面和内容的本地化提供了完善的内建支持。
xbb设计的中心是可扩展性，在xbb的设计上，没有任何“一步到位”的构想，一切都为改变和扩展服务。程序员描述的实体模型被作为整个系统的中心，这个中心是可扩展的，永远都可以继续添加、描述新的数据、信息模型，而界面和永久化层的其他组件都为这些模型服务，也同样可以永远不断扩展下去。
与Casctle、MVC、DNN等快速开发框架完全不同，xbb没有对开发模式进行太多限定。xbb的所有组件都和.Net类库本身紧密结合，更像是.Net框架的一个补丁，.Net框架本身的一部分，用户可以按照.Net框架本身的开发风格来使用xbb提供的各种组件，可以在xbb基础上设计三层、七层等符合实际需求的架构模式。
虽然xbb最初被设计为用于线上社区项目的开发，但后来由于工作需要，xbb被直接拿来开发OA项目，并且很好地证明了其可扩展设计，可以很好地适应扩展和改变。
xb，ExtensibleBase，“可扩展库”或者“可扩展基”，数据库（Database）满载着数据，知识库（Knowledgebase）满载着知识，ExtensibleBase是满载着可扩展性的开发架构。
回想一下：
.Not提出了“记录一切”的概念，设计成一个以实体模型和自描述性为中心的架构，侧重于实体和数据模型的设计。
xbb仍然以记录一切的模型为中心，完善了用户交互和数据持久层的设计，展现了一个完整的快速开发框架。
xb开始以架构设计本身为中心，开始有点小型开发框架的意思。
直到目前为止，三次架构设计，都是围绕“记录一切”这个最初的“设计梦想”展开，所以可以被视为一个架构的三期设计和开发过程。
由于在上一代架构上进行了几个OA项目的开发，所以原来用的xbb这个名字就有点不合适了，于是去掉了一个“b”，换成了xb这个更有架构味道的命名，同时伴随的还有一系列的新设计。
之所以说xb开始有点小型“开发框架”的意思，是因为xb从开始就被明确设计成一组完成各自职能的组件，他们正在开发或正在计划开发中，下面介绍一些主要组件：
xb（http://codeplex.com/xb）：在上一代的xbb系统中完成的在运行时对ASP.NET控件和LINQ数据层进行动态、智能化控制的功能在xb中被继承下来，并被称作“运行时控制（RuntimeHanbler）”组件部分，与之对应的是新的“设计时创建（DesignTimeCreator）”组件部分，在新的xb架构中两者占有同样重要的地位。
seed（http://codeplex.com/seed）：seed的命名思路是，一颗小小的，带有基因密码的种子，被培植、成长成枝繁叶茂的参天大树。
seed完成的是xb架构中设计时创建者（DesignTimeCreator）的角色，简单地说，就是代码生成器，但是又是很不同的代码生成器：
“class People { string Name { get; set; } int Age { get; set; } Profession Job { get; set; } }”
在这里我把这样的一段代码称作一个seed，他就承载了一个应用的信息和特征，开发人员只要写下这样简单的代码，这种基于面向对象语言的模型声明，seed工具就可以用他来创建完整的网络应用了。
使用seed不仅异常简单，其实seed还有强大的可定制性，比如：
“[Locallize("员工", "zh-CN")] class Employer : People { [DisplayName("No."), Category("用工信息"), Char(9)] string EmployerNumber { get; set; } }”
这个Employer实体模型会继承People的所有属性，根据生成规则，它可以在界面上或数据库中被叫做“员工”。EmployerNumber在界面上会被显示成“No.”，当被分类时会被分在“用工信息”分类下，在SQL Server数据库中会被创建为Char(9)类型。
在之前的几个商业项目中，客户要求不断改变，总得不断地交流，修改程序，再去交流，不但效率低，而且开发工作枯燥乏味。我就想能把框架做成可以适应频繁变化的，能在客户描述了新的调整和功能后，马上就能看到软件的运行效果。
有了seed后，我把建站策略事先写好，和客户进行交流时，只需要关注业务需求本身，描述好业务需求后就可以运行应用看到结果了。后来，我听到一些开发上的前辈，也有和我一样的构想，他们把这称作“极限设计”。
其实这个目的，早在xbb架构中就已经实现了，也就是说，xb中的“运行时控制”或“设计时创建”体系，都可以完成进行对象模型后就直接可以运行应用程序的目的。但两者的区别在于：
xbb架构的中心，“运行时控制者”体系会在运行时对模型声明进行分析，然后动态控制ASP.NET运行时，调用各种控件和LINQ数据访问。
xb架构新增的“设计时创建者”体系，会根据模型声明一次性创建经典、标准、完整的ASP.NET应用程序，就好像是由程序员创建的一样，创建后的站点会和经典ASP.NET站点一样工作。这种模式具有以下改进：
像控制者模式一样，创建者模式也能对架构中已经支持的模型和事物类型进行快速开发，20分钟内可能完成两天的工作，而创建者模式中，还可以对生成的项目进行再开发、再加工，从而支持架构本身还没有编入的模型、事物类型。
控制者模式由于大量利用了泛型、表达式和多态等设计、工具来达到了很高的抽象性，结果导致了调试上的困难。新的创建者模式由于生成最经典、最基本、最简单的标准ASP.NET站点，基本上所有东西都有明文，数据访问也可以在SQL语句和LINQ之间自由选择，对调试和阅读理解更加友好，很容易了解到整个系统的每个细节到底在怎样工作，便于排错。从xb架构开始还引入了完整的测试驱动开发模式。
由于两者在分析模型生成应用时用的其实都是一样的策略，所以其实可以在创建者模式中调试好策略然后在控制者模式中使用，一定程度上弥补了控制着模式不便于调试、排错的弱点。
如果我自己认真地开发一个有一定规模的应用，我更倾向于使用控制者模式，因为架构的整体性、策略性更好，而对于日常的商业项目、OA开发，则使用创建者模式更好，这样可以缓解在框架中短时间内扩充大量新模式、事物类型的需要。从单个项目或者眼前的需求出发，根据实际情况扩充xb架构或者在创建出的ASP.NET应用上进行二次开发。
事实上seed只是一个调用者，它的职能是由两个子项目完成的，这两个子项目虽然为seed服务，但是他们都各自有完整的功能，都可以单独使用：
LINQS（http://codeplex.com/LINQS）Language Intergrated Query Server，LINQ Server：
如果用一句简单的话概括目前LINQS中完成的工作，我觉得可以把它比喻成一个针对丰富数据类型的XSL体系，提供了丰富数据、信息模型之间的转换和常用操作。
从长远的计划来说，SQL Server是SQL的执行平台，LINQ Server也会成为LINQ的执行平台，提供一个开放的、丰富的（.Net）框架内的数据操作平台。
LINQS现在可以在以下结构、模型之间进行转换工作：
种子（用C#等语言写的面向对象的模型、实体描述）、
SQL Server 2005、2008数据库模型、
LINQ to SQL数据访问层和Dbml数据模型描述等。
短期内可能加入：
Oracle、Sqlite、Access等其他数据库模型描述、
EntityFramework数据访问层和Edmx模型等。
除了模型间的转换外，LINQS还能直接调用SQLServer完成数据库创建、增删改查等各种操作，也可以输出脚本。
xp（http://codeplex.com/xp）ExtensiblePresetation或者eXPressive：
与LINQS项目配合，xp是用来生成界面、用户交互层，或者说ASP.NET站点的。在本项目中，定义了一系列的高抽象性的xp控件，使用这些控件要比使用ASP.NET控件简单得多，描述一个xp应用程序只需要描述它有哪些页面，每个页面中对哪些数据模型进行管理既可。当然了也可以从一个种子自动生成xp应用。
通过和LINQS中类似的模型转换模式，目前xp项目可以把一份xp应用程序描述转换成简单的ASP.NET应用程序，它具有从xbb继承下来的优点，比如说可以对流布局提供完美的支持，可以进行高复杂度的排版。接着会让他支持生成Silverlight站点，不久的将来会加入Dynamic Data站点。
在LINQS和xp的架构设计上，都充分考虑了其开放和可扩展性能，也就是说很容易在它上面扩展其他的生成策略，Ruby on Rails、PHP站点的生成都是可行的。而且第三方的扩展可以像原生组件一样完美地工作。
？（名称暂时保密）按照微软的一贯风格，xb作为一个微软开发社区中的小型开发框架，没有友善的可视化开发工具怎么能行呢？
这是一个小型开发工具项目，在本项目中，我们给seed开发一个界面，一个基于seed的线上应用程序。
虽然说使用seed进行快速开发已经非常简单，但对于那些没有学并且也不想学习编程语言的用户，他们就可以通过这个开发工具体验seed带来的快速开发体验。
定义一个seed模型是如此的简单，所以制作和使用一个定义seed模型的图形化工具当然也不是什么难事。
在本项目应用中，大家可以在线创建、交流自己的应用模型，可以交换自己创建的界面控件和风格，生成项目后既可下载或者部署到自己的ASP.NET主机上。
通过调用seed，这个小型工具将可以生成ASP.NET、Silverlight、Flex等各种采用时髦技术的站点应用。
此外，xb还有一系列案例项目，他们都使用xb框架提供的开发能力来创建，用来测试和演示xb的功能，目前包括一个个人档案管理程序，一个项目管理、跟踪程序和一个根据AdventureWorks数据库开发的OA。
用xb开发出的OA和其他类型应用，有一个最大的，根本性的区别，由于xb沿用了“记录一切”的中心思想，所以xb应用中管理的所有信息都自然连通，原生就在同一个系统中。与其他的OA等应用要遭遇集成问题相反，xb的应用原生即集成在一起，并且也可以按需要拆分。
WuKong：
xb框架到目前为止已经进入了第了三个阶段的设计和开发，下一阶段的xb会是什么样，朝什么方向去呢？在我的头脑风暴里，答案可能是人工智能系统。
在seed项目中，我们教会了计算机怎样像程序员一样开发软件，未来也许还可以让它学会更多。
WuKong是目前xb设计中用来完成一些自动工作的组件。
这些项目都在CodePlex上托管，大家可以打开项目地址后，查看Issue Tracker页面，在这里可以正在处理和接下来需要处理的工作，如果您感兴趣就可以直接联系我加入了。
另外我正和朋友在社区里组织一个商业的Silverlight游戏开发项目，如果您感兴趣同样欢迎参加。
176
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
