摘要：
http://blog.csdn.net/hliq5399/category/297103.aspx 阅读全文
摘要：
前言：PetShop是一个范例，微软用它来展示.Net企业系统开发的能力。业界有许多.Net与J2EE之争，许多数据是从微软的PetShop和Sun的PetStore而来。这种争论不可避免带有浓厚的商业色彩，对于我们开发人员而言，没有必要过多关注。然而PetShop随着版本的不断更新，至现在基于.Net 2.0的PetShop4.0为止，整个设计逐渐变得成熟而优雅，却又很多可以借鉴之处。PetShop是一个小型的项目，系统架构与代码都比较简单，却也凸现了许多颇有价值的设计与开发理念。本系列试图对PetShop作一个全方位的解剖，依据的代码是PetShop4.0，可以从链接http://msdn 阅读全文
摘要：
1.框架的概要介绍微软刚推出了基于ASP.NET 2.0下的Pet Shop 4, 该版本有了一个全新的用户界面。是研究ASP.NET 2.0的好范例啊，大家都知道，一直以来，在.NET和Java之间争论不休，到底使用哪个平台开发的企业级应用性能最好、结构最优、生产力最高。为了用事实说话，通过对项目各方面的性能评估进而在比较.NET和Java的高下。用户做比较的这个项目就是Petshop。正因为Petshop肩负着上面所说的重任，各方面必须是最优的，架构设计应该是经过慎重考虑的。所以其一经推出，便成为了开发者、架构师等人学习、研究的典范。日前微软推出了基于.NET Framework 2.0开 阅读全文
摘要：
PetShop数据库解读PetShop数据访问层之数据库访问设计PetShop的工厂模式PetShop之业务逻辑层设计PetShop数据库解读PetShop 4.0使用了四个数据库，分别为：MSPetShop4 、MSPetShop4Orders 、MSPetShop4Profile 、MSPetShop4Services 一、MSPetShop4其中MSPetShop4用来管理产品、分类等基本数据信息，其中共有六个表 AspNet_SqlCacheTablesForChangeNotification Category Inventory Item Product Supplier Cate 阅读全文
摘要：
从这篇文章开始我会引入一些领域上的知识或者给出一些参考文章来供大家阅读，我们对这些领域上的知识没有必要深挖，只要大概了解一下就可以了，这对于我们分析BlogEngine.Net会有很大的帮助。在这篇文章中我主要向大家介绍一下BlogEngine.Net的搜索部分的实现以及支持的相应标准等。先用自己的话解释一下什么是开放搜索 开放搜索应该也是一种标准了，现在它越来越流行起来，记得我第一次见到这个东东是在codeproject中。大家一定注意到了IE7右上角的那个小工具栏了，附件: OpenSearch.jpg 我们可以在那里选择一个搜索提供程序例如:Google，当我们输入信息回车以后就会发现页 阅读全文
摘要：
在这篇文章中我们将对BlogEngine.Net的全局配置进行一下分析与探讨。关于配置这一部分单独拿出来做一篇文章实在有些牵强，但是我总觉得这个配置部分比较独立，而且BlogEngine.Net的设计和实现都有很多可以参考的地方。在一个企业级应用系统中，对一些系统全局参数进行配置是必不可少的，那么我们是怎么处理这些配置的呢？ 一般都有以下三步：1.在业务模块开发的过程中将一些可变的参量提取出来。2.当所有业务模块开发完成时，将这些参量分类存储起来。3.开发出相应的管理功能，允许用户对这些参量进行设置。 相信大多数开发者都是直接操作数据库中的数据，可能有些比较完善的系统会做出单独的页面来给用户管 阅读全文
摘要：
在上一篇文章中，我们主要分析了一下BlogEngine.Net的整体设计，在后半部分我们又对BusinessBase业务对象的状态维护做了一些比较深入的探讨。在这篇文章中我将引领大家完成对BlogEngine.Net中业务对象数据存储的设计思路与实现细节的分析。BlogEngine.Net中的数据存储主要是应用Provider模式实现的，那么首先让我们认识一下Provider模式。 Provider模式应该是一种设计模式，是用来解决软件变化问题的。不过它关注的角度（或者维度）是功能声明跟功能实现的分离。一般来说，系统对某一功能的需求可能是相对稳定的（比如每个系统都要求对登录用户进行验证，这个需 阅读全文
摘要：
上篇文章朋友的评论给了我很大的动力写这个系列的文章，看来大家都比较关注这个系列。为了后续文章做一个铺垫，我在这篇文章的前半部分讲解一下BlogEngine.Net的整体架构，后半部分主要是对于BusinessBase类的分析。下载源代码以后打开解决方案，我们发现从项目的组织结构上BlogEngine.Net分成两个项目：一个是BlogEngine.Core，顾名思意，它就是BlogEngine.Net的核心逻辑层。所有的业务逻辑和一些功能都在这个项目中体现，实际上这个核心业务层中也有数据访问的一部分，那就是Provider模式。在BlogEngine.Net中，关系数据库或XML等的作用只有一 阅读全文
摘要：
近我要开始这个系列了，这是我的第一个系列。关于BlogEngine.Net我想说的是，它设计的真的很棒，代码简洁但是功能很多，真是麻雀虽小，五脏俱全啊，而且具有了很多Web2.0的特征，甚至它的每一行代码都值得我们去研究一下，它的开发团队很棒。实际上很多国外的个人Blog都是采用BlogEngine.Net加上自定义皮肤实现的，如果您是一个Blog的开发者，这更是您的必备参考！ 很多兄弟都推荐BlogEngine.Net看一看，甚至www.asp.net也把它放在了很重要的位置。前一阶段我仔细的把它的源代码阅读了一遍，看完以后兴奋的很冲动，心想居然还有这么好的玩意，这个开源项目设计的真的不错。 阅读全文
摘要：
在这篇文章中，将讨论一下表示层的实现方法。 表示层是一个系统的“门脸”，不论你的系统设计的多么优秀，代码多么漂亮，系统的可扩展性多么高，但是最终用户接触到的大多是表示层的东西。所以，表示层的优劣对于用户最终对系统的评价至关重要。一般来说，表示层的优劣有一下两个评价指标： 1.美观。即外观设计漂亮，能给人美的感觉。 2.易用。即具有良好的用户体验，用户用起来舒服、顺手。 表示层的设计牵扯到很多非技术性问题，如美工、用户心理学等问题，但是在这篇文章中，将不过多涉及这些问题，一来是我的水平有限，二来是这些内容和本系列文章的关系不是很密切。这里将主要从技术实现的角度讨论表示层的设计。 一般来说，表示层 阅读全文
摘要：
在这一篇文章中，将实现一个NGuestBook的业务逻辑层。 在实际应用中，业务逻辑层是至关重要的，他承载着整个系统最核心的部分，也是客户最关注的部分。这一部分的实现，通常需要技术专家和领域专家通力合作。当然，在本文章系列的Demo中，由于业务逻辑的简单性，这里看的可能还不是很明显。 在本篇文章的业务逻辑层实现中，业务逻辑层主要承担了以下职责： 1.对不同数据访问层的封装。使得表示层可以不关心具体的数据访问层。 2.业务逻辑数据的填充与转换。如管理员口令的加密。 3.核心业务的实现。这里很多业务逻辑只有一行代码，即一个业务逻辑方法恰好对应一个数据访问方法，但是也有通过多个数据访问方法实现业务的 阅读全文
摘要：
前面的文章讨论了使用SQL语句和存储过程两种数据访问层的实现方式，这一篇里，将讨论使用ORM方式实现数据访问层的方法。 对象-关系映射（Object/Relation Mapping，简称ORM），是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法，关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存 阅读全文
摘要：
在上一篇（基于.NET平台的分层架构实战（七-外一篇）——对数据访问层第一种实现（Access+SQL）的重构）中，讨论了使用SQL构建数据访问层的方法，并且针对的是Access数据库。而这一篇中，将要创建一个针对SQLServer数据库的数据访问层，并且配合存储过程实现。 曾经有朋友问我使用SQL和存储过程在效率上的差别，惭愧的是我对这方面没有研究，也没有实际做过测试。通过查阅资料，发现在一般情况下，存储过程的效率由于使用SQL，但是也不绝对，也发现有的朋友测试时发现在特定情况下SQL的效率优于存储过程，所以这个问题不能一概而论。 好，废话不多说，这里先列出使用存储过程构建数据访问层的一般步 阅读全文
摘要：
昨天的文章 基于.NET平台的分层架构实战（七）——数据访问层的第一种实现:Access+SQL 发布后，很多朋友对我的程序提出了意见和建议，在这里先谢谢你们！！！尤其是 金色海洋（jyk），对我的程序提出了很多建设性的意见。 我大体总结了一下，昨天程序的主要缺点有： 1.Connection对象没有关闭 2.DataReader对象没有关闭 3.相似代码太多，造成代码冗余。 其中第一点问题，目前还没有太好的解决方案，主要是因为Connection一旦关闭，DataReader就无法读取了。而且，Connection对象应该会自动在适当的时候关闭（通过观察临时文件得出），并且在实际运行时并无影 阅读全文
摘要：
经过上面篇文章的介绍，整个系统的框架算是基本搭建完了，下面，我们要具体实现各个层次。关于数据访问层的实现，我准备讨论三种实现方式，这一篇文章讨论第一种：Access+动态生成SQL。 顾名思义，这种实现将使用Access作为后台数据库，而操作方式也是最基本的使用SQL命令。 在具体编写实现代码之前，我们需要做一些准备工作： 第一步，我们要将Access数据库搭建完成，具体做法如下。 在Web工程下新建一个文件夹，命名为AccessData，并在其中新建一个mdb文件（即Access数据库文件），按照前面介绍过的数据库设计构架，将数据表及表间关系建好，这里不再赘述。 第二步，我们要进行一些配置。 阅读全文
摘要：
我们设计的分层架构，层与层之间应该是松散耦合的。因为是单向单一调用，所以，这里的“松散耦合”实际是指上层类不能具体依赖于下层类，而应该依赖于下层提供的一个接口。这样，上层类不能直接实例化下层中的类，而只持有接口，至于接口所指变量最终究竟是哪一个类，则由依赖注入机制决定。 之所以这样做，是为了实现层与层之间的“可替换”式设计，例如，现在需要换一种方式实现数据访问层，只要这个实现遵循了前面定义的数据访问层接口，业务逻辑层和表示层不需要做任何改动，只需要改一下配置文件系统即可正常运行。另外，基于这种结构的系统，还可以实现并行开发。即不同开发人员可以专注于自己的层次，只有接口被定义好了，开发出来的东西 阅读全文
摘要：
接下来，将进行接口的设计。这里包括数据访问层接口和业务逻辑层接口。在分层架构中，接口扮演着非常重要的角色，它不但直接决定了各层中的各个操作类需要实现何种操作，而且它明确了各个层次的职责。接口也是系统实现依赖注入机制不可缺少的部分。 本项目的接口设计将按如下顺序进行： 1.首先由前文的需求分析，列出主要的UI部分。 2.分析各个UI需要什么业务逻辑支持，从而确定业务逻辑层接口。 3.分析业务逻辑层接口需要何种数据访问操作，从而确定数据访问层接口。 另外，为保证完全的面向对象特性，接口之间的数据传递主要靠实体类或实体类集合，禁止使用DataTable等对象传递数据。 由需求分析，列出主要UI 需求 阅读全文
摘要：
实体类是现实实体在计算机中的表示。它贯穿于整个架构，负担着在各层次及模块间传递数据的职责。一般来说，实体类可以分为“贫血实体类”和“充血实体类”，前者仅仅保存实体的属性，而后者还包含一些实体间的关系与逻辑。我们在这个Demo中用的实体类将是“贫血实体类”。 大多情况下，实体类和数据库中的表（这里指实体表，不包括表示多对多对应的关系表）是一一对应的，但这并不是一个限制，在复杂的数据库设计中，有可能出现一个实体类对应多个表，或者交叉对应的情况。在本文的Demo中，实体类和表是一一对应的，并且实体类中的属性和表中的字段也是对应的。 在看实体类的代码前，先看一下系统的工程结构。附件: f3.jpg 如 阅读全文
摘要：
本文主要是对将要实现的架构进行一个总体的描述，使朋友们对这个架构有个宏观上的认识。这篇文章理论性的东西会偏多一点，从下篇开始，将进行实际项目的开发。这篇文章的许多内容摘自我的毕业论文。架构基本原则： 这里，将描述一些在这个架构设计中的基本原则，其中很多都是经典的设计原则，不过针对分层架构的特点，用我自己的语言进行了描述。其中也有我自己提出的原则。 逐层调用原则及单向调用原则 现在约定将N层架构的各层依次编号为1、2、…、K、…、N-1、N，其中层的编号越大，则越处在上层。那么，我们设计的架构应该满足以下两个原则： 1.第K（1<K<=N）层只准依赖第K-1层，而不可依赖其他底层。 阅读全文
摘要：
在实际的项目中，需求分析和数据库的设计是很重要的一个环节，这个环节会直接影响项目的开发过程和质量。实际中，这个环节不但需要系统分析师、软件工程师等计算机方面的专家，还需要相关领域的领域专家参与才能完成。 但是，在这个文章系列中，所要使用的Demo仅仅是一个例子，而且其业务极为简单，因此，这里并不是真正的需求分析和数据库设计，而是将Demo的需求和数据库罗列至此，使朋友们对Demo有一个大体的了解，方便后续文章中开发过程的理解。需求分析： 这个项目是一个留言本，其业务极为简单，现将其描述如下。 1.任何访问者可以进行留言，留言完成后，不会立即显示正文，而是要经过管理员验证后才可显示。 2.任何访 阅读全文