随笔分类 - 其它 / 系统架构
摘要：回到目录上回主要把数据操作规范及EF两种基类下的实现说了一下，今天主要针对ObjectContext情况下的批量操作作一个详细的说明，首先，要说明一点，批量操作不用ObjectContext提供的方法，而是使用拼SQL串的方式，将列表拼成一个SQL串，一次的发给数据库，这样在性能上绝对是一个质的飞越，本人尝试过，无论是EF还是linq to sql，它们提供的方法，对于列表的操作会产生N条SQL串（N＝列表的长度）。一个操作类型枚举：1 /// <summary>2 /// 執行SQL的類型3 /// </summary>4 pu...
阅读全文
摘要：回到目录在EF环境里，我们的数据上下文对象通常是有两个版本，一个是DbContext对象，另一个是ObjectContext，个人觉得前者是轻量级的，对于code first模式中使用比较多，而后者是原生态的，最初的EDM（entity Data Model)就是以这个为基类的，它的实现与linq to sql很类似，也是分部方法，lambda表达式等元素的产物。看看我的一个规范，两个实现吧！一个规范： 1 namespace Commons.Data 2 { 3 /// <summary> 4 /// data repository interface 5 ...
阅读全文
摘要：MVC3+EF+Autofac网上这种文章确实没有，呵呵，今天就写一个，代大家分享！这个系列的文章将带我们进入一种新的开发模式，注入开发模式，或者叫它IOC模式，说起IOC你可以这样去理解它，它为你的某个实现流出一个注入点，你生产的对象，可以根据你之前的配置进行组合，这是可以的。而注入点的位置及方式也是多种多样的，我们今天主要说一个通过HTTP请求进行注入的方式，IOC工具使用高效的Autofac,对它的认识你可以看这篇文章。首先看一下我们这个项目的知识点：MVC3~一个对UI层进行分层的架构模式，在微软的MVC3中加入了开源的Razor引擎EF~这无疑是微软自己比较成功的ORM工具，它执行效
阅读全文
摘要：在linq to sql作为底层数据源时，我们进行一个linq返回结果集的操作，这没有问题，不过，当你进行update操作之后，再使用linq返回结果集时，你会发现，它返回的信息是不正确的，或者总是发生变化的，这是为何？事实上，这是由于DataContext本身的机制所决定的，它本身就有缓存机制，当你从数据库把信息得到时，然后修改它，再进行保存，如果你再把信息取出来，这时，你会从datacontext的缓存中得到，而不是真正的数据库里得到，这个datacontext缓存如果想要解决，有几种方法：1 datacontext不要共享化（不要静态化，不要单例），使用私有datacontext，即每.
阅读全文
摘要：回到目录 在使用Linq to Sql做为底层ORM时，它为我们提供的数据上下文为DataContext对象，实现上我们通过拖动生成的DBML文件，它们都是继承自System.Data.Linq.DataContext类型的，所以DataContext就是LINQ数据对象的基类，有时，我们可以通过这种类的多态性来动态创建DB的实例。 在每个DataContext类中，它有几个实例的构造方法，用来让你创建DataContext的实例，如下： 1 /// 2 /// 使用默认的连接串创建实现（每拖一次数据库，就会产生一个连接串） 3 /// 4 ...
阅读全文
摘要：回到目录 我们在使用linq查询时，你的数据源可能是linq to sql或者是ef产生的，但只要是使用linq的语法去实现一个查询，就有可能出现“查询包含对不同数据上下文上所定义项的引用”的异常，这个异常很明显，是你在进行join表关联查询时使用了多个不同的DataContext对象，这是linq不允许的。有了这个异常，就会出现一些解决方案，以下是我们可能的一些做法：１ 使用全局的static对象，但对于linq to sql来说，在高并发时，这个static对象会抛出一些莫明奇秒的异常，那时，我们会说，linq to sql不如ado.net靠的住。２ 使用单例模型创建对象，保证它在所有.
阅读全文
摘要：回到占占推荐博客索引 本系列文章主要是我在工作中，遇到一些不能主观判断的问题，最后在电脑上去证明我的理解是否正确，这也是题目“将不确定变成确定”的由来。 记得我在上大学时，老师说过一句话：“机器最能证明一切”，这句话现在看来，确实很经典。 将不确定变为确定系列~目录（“机器最能证明一切”） 第一回
阅读全文
摘要：回到目录我之前写一篇关于事件订阅的文章（事件的好处~实现对修改的封闭，对扩展的开放!~续），但它主要是订阅静态事件，而今天主要讲的是实例事件，即，当一个事件发布者被实例化后，去订阅它里面的事件，然后当这个事件发布者去触发该事件时，自己执行你订阅的内容，这没什么可说的，一切都很正常。但在B/s系统中，常常都有这样一种需求，即：Order类中有方法GeneratorOrder，即生成订单的方法，这个方法会被ＵＩ层的很多方法调用，以实现对不同业务产品的购买，如：购买家电产品，购买成功后应该去和家电有关的成功页；而购买日常用品，成功后应该去与日常用户相关的页面；以后还会有其它业务产品的成功页，需要我们
阅读全文
摘要：在面向服务中讲配置文件，肯定是要把它与具体领域分离，即它有普遍的一般性。在程序开发过程中，难免会用到一些易变性，全局的常量信息，我们通常的作法是把它们放在Web.config或者自定义的文件中，当然你的配置文件可以是ＸＭＬ，二进制的等等，但一般时候我们选择用ＸＭＬ标准的文件。看全局配置项目的结构如下...
阅读全文
摘要：回到目录如果您看到这个题目，觉得有点怪，那说明你是一个高人，最起码比我高的多，呵呵。前几天做了一个公用后台管理系统的项目，其中有一个地方涉及到权限管理的，即为每一个按钮赋一个权限，然后它权限汇总到角色表里，即一种角色有一些操作权限，表结构如下：我们看到OperatorAuthority就是操作权限的意思，它是个int类型的，一个role有一个OperatorAuthority,那我们应该怎么把多个权限存储到OperatorAuthority字段里呢？这时，我想到了枚举类型的位运算，所以我把权限枚举设计成了这样： 1 [Flags] 2 public enum UserOperato...
阅读全文
摘要：回到占占推荐博客索引这个系列写的我有点筋疲力尽，文章的复杂度超过了我的想像，其中在很多朋友的回复中可以看出，我的基础知识还需要提高及语言表述能力也需要提高，在此，谢谢各位的好心回复。这个系列写完成后我有个承诺，那就是把核心代码以附件的形式共享出来，如果有需要，可以单击此处进行下载。事实上“改善程序复用性”的本质应该就是你是否遵循了面向对象的原则，你的代码是否面向对象，可能一个方法的重构，一个类的抽象就是一个改善你程序复用性的方法之一，复用性是一点点实现的，它不是在最后阶段进行代码review时进行完成的，而是关系到代码从开发到完成的整个阶段。架构，改善程序复用性的设计~目录(附核心原代码)第一
阅读全文
摘要：N层架构及各层之间的通讯标准一 总体结构图二 各个模块的介绍通用项目模块Project.Common：它是对所有项目都公开的项目组合，主要提供一个与领域无关的通用功能的代码库核心项目模块Project.Core：它是针对某种构架方式（如LINQ To SQL作为底层架构）抽象出来的项目组合，它与领域无关领域项目模块，它是具体的项目，如XXB项目，它本身也是一个N层架构方式，一般地，它的UI层会继承我们的Product.Core下的Web.Commons项目，而对应的Entity对应Entity.Commons项目，由于BLL层是针对某种特殊业务领域的，所以在Project.Core里没有出现B
阅读全文
摘要：从本文标题中可以看出，主要说的是反射技术和控制反转（IOC）技术，本文主要先介绍一下我对这两种技术的理解及它们的优缺点，最后再用实例来说一下使用方法。反射：可以使用反射动态创建类型的实例，将类型绑定到现有对象，或从现有对象获取类型并调用其方法或访问其字段和属性。这里，它最重要的是“动态性”，即根据条件动态创建“指定类型”的“实例”。1 // Using GetType to obtain type information:2 int i = 42;3 System.Type type = i.GetType();4 System.Console.WriteLine(type);结果是：Syst
阅读全文
摘要：在第三讲中我们主要关注了代码重构的思想，从方法重构到类重构再到项目重构，这是一个过程，一种思想上的升华，今天将继续我们“程序复用性设计”的旅程，说一下方法重载的重要性。细心的朋友一定会非常关注net frameworks的源代码，即使只能看到它内部方法的定义，也足够了，在System.Web.Mvc这个命名空间下定义了很多关于MVC架构的东西，我们就以它为例来说一下方法重载吧！重载的好处：1 对方法调用的程序员来说，它是友好的（程序员只关心自己调用的方法签名即可，不用管参数为NULL怎么办这些逻辑）2 对于代码维护量来说，它是容易的（核心代码只放在参数签名最多的方法中）3 对于代码扩展来说，它
阅读全文
摘要：在写完架构，改善程序复用性的设计~第三讲 实现一种功能的代码只能出现在一处 ， 这篇文章后，得到了园友的反馈，说这种简单的业务逻辑还可以，但业务比较复杂时，根据就没法用这种方法。针对这个问题，我觉得有必要再写一个续集了，呵呵！上回说的主要核心内容是将公用的部分从一个方法中提取出来，生成一个新的方法，这个重构中叫做“提取到方法”，另外一个核心内容就是方法的”单一职责“，即一个方法干一件事，将出现复杂事件时，将多个方法进行组合调用即可这回主要说一个重构中的提取，其实不仅方法可以被提取，类，及整个项目也可以被提取，只要他们有被提取的必要！一个例子：对于一个数据实体操作的基类，它包括了其它所有实体类共
阅读全文
摘要：从标题中可以看到本篇文章将介绍代码随意性的缺点及由此引发的后果，首先，来说一下同一功能的代码在多个程序中被编写多次的后果：1 它破坏了面向对象的“单一职责”的原则2 当代码逻辑复杂时，或者进行二次开发时，程序员将对方法调用产生歧义，即不知道应该使用哪个方法，即代码可读性差3 当这个不规范的方法逻辑需要修改时，你将会进行多次重复的调整，这是一个程序不希望做的事解决方法：当几个模块需要用到同一功能，或者功能相似的方法时，应该先将公用的功能抽象成一个新的方法，再把不同的地方抽象成其它方法，这也就是《重构》中的extract method 。下面看一下代码：不规范的：View Code 1 p...
阅读全文
摘要：之前我完了《重构，改善即有代码的设计》，这本书非常适合在编程中遇到瓶颈的朋友，看完 这本书，一定让您有一种“拨开迷雾”的感觉，事实上这本书就像标题一样，主要是讲代码重构的知识的，从变量命名到语句编写，从语句到提取方法，从方法重构 到类重构等等，每一篇文章都像是一道菜，让看过的人回味无穷，在这里班 下Martin Fowler大师。今天有点兴趣，准备按下来的几一写一下最近的作品《架构，改善程序复用性的设计》，主要从系统架构的角度，来设计一个可能被多个系统重用的公用项目集，下面是本课程的目录部分：第一讲 系统的复用性离不开系统的面向对象性第二讲 什么应该提取出来，什么应该保留第三讲 实现一种功能的
阅读全文
摘要：前言说明:这里说的"接口"并不是C#时的interface,而一般指定一个方法签名,它一般为外部提供一个GET请求,接口到请求后,进行处理,然后对调用方进行信息的返回.回到本题中来,事件上,我们坐下来,认真去想想,还是统一接口的比较好,如果要具体业务使用具体接口,那它的具体接口肯定也是去再调用一下"那个统一的入口模块"的,注意,这里我说的是"模块",而不是"接口,类,方法等"大体流程应该是这样:客户端调用某个服务接口接口系统调用某体业务前的逻辑 创建一个具体业务调用某体业务后的逻辑返回给客户端对于一个服务端的代码要
阅读全文
摘要：本系列将带您一步一步开发一个.net MVC,底层用linq to sql作为ORM的WEB应用程序,主要讲的不是开发细节,而是整体的架构方案,事实上,大部分项目架构的方式都是类似的,主要都是为业务层提供一个稳定的,可扩展的数据层,本系列主要是讲如何去设计一个基于数据仓库的Repository数据操作模型.第一回 MVC+LINQToSQL的Repository模式之(一）数据工厂第二回 MVC+LINQToSQL的Repository模式之(二）数据基类第三回 MVC+LINQToSQL的Repository模式之(三）Repository模式实现统一CURD操作，实现EF中的Find主键查
阅读全文
摘要：在进行项目整体架构设计时，我们应该明确知道哪些项目是可以被重复再利用的，而哪些项目是与领域模块关系密切的，对于后者我们是应该在解决方案中保留的，而前者则是应该提取出来的。在一个完整的解决方案中，应该是由“公用的类库”，“核心的项目基础层”和“与业务领域关系密切个性项目组”组成的，对于我开会的那个项目来说，也是遵循这样一个原则：将与领域和项目无关的项目进行抽象，形成一个最基础的层，称为Project.Common将与架构模式有关，而与领域无关的项目，形成一个架构模式核心层，称为Project.Core将与指定领域有关的，个性化业务组成的代码，叫做领域层，它的名称由项目含义确定在这篇文章里，我们主
阅读全文