随笔分类 - 其它 / 系统架构
摘要：回到目录这个文章写的有点滞后了，呵呵，因为总想把之前不确定的东西确定了之后，再写这篇，之前的LINQ-to-SQL那点事，请点这里。LINQ-to-SQL中的数据缓存与应对Linq-to-SQL它是微软自己推出的一个轻量级的ORM框架，它很好地完成了与SQLSERVER数据库的映射（它目前只支持SQLSERVER，也不会有以后的，因为微软不对它进行更新了），在使用它时，微软提出了“数据上下文”的概念，这个上下文（context）类似于HttpContext,RequestContext，是指对某种事物的完整的抽象，把对这种事物的操作都集成在上下文中。Linq-to-SQL的上下文被称为Data
阅读全文
摘要：回到目录之前写过三篇这个文章系列，都是围绕一个主题，那就是.net何时将transactionscope提升为分布式事务，今天我借用ThreadStatic特性，把这个知识点又证明了一下，下面总结一下：transactionscope文章：第二十六回 将不确定变为确定~transactionscope何时提升为分布式事务？第二十七回 将不确定变为确定~transactionscope何时提升为分布式事务~续第二十八回 将不确定变为确定~transactionscope何时提升为分布式事务~再续（避免引起不必要的ＭＳＤＴＣ）ThreadStatic特性文章：基础才是重中之重~ThreadSta.
阅读全文
摘要：回到目录static修饰符我们不会陌生，它代表静态，可以修饰你的类，方法，字段和属性等等，今天主要说一个为静态字段加ThreadStatic特性会给程序代来什么样的变化。静态字段static field，我更习惯称它为“类的字段”，即它与类的具体实例无关，对于所有线程里，它的值都是一个，即它的唯一性。如代码：class Instance{ static DataContext context=new LinqToSql(conn); protected static DataContext {get{return context;}}}上面的代码中，context为静态字段，它的值在所有...
阅读全文
摘要：回到目录用工作单元带给我们的是什么？... 11. 相关说明2. 优化查询3. 优化SubmitChanges4. 优化TransactionScope5. 核心代码1. 相关说明工作单元的接入，保证了数据上下文在一个操作单元中只有一个，它可以通过构造方法注入到其它类中，实现跨类进行方法的组合。2. 优化查询上面的问题产生的场合应该是：你用了join语句，你的join语句与from语句所使用的数据上下文不是一个（DataContext）解决方法：将数据上下文变成一个就可以了，这就是之前我们一直用的线程单例模式出现的原因，而往往一个方法可能需要引用多个类中的方法，这时，线程单例将不能解决这个问题
阅读全文
摘要：回到占占推荐博客索引经过两周的努力，终于把这个系列写完了，这段时候正好赶上项目改版，所以也像自己的项目重构了一下，将IUnitOfWork思想注入其中，希望对系统有所帮助，那是必然的，呵呵，IUnitOfWork的出现主要还是体现在性能上，下面看一下目录：说说IUnitOfWork~目录第一讲 说说IUnitOfWork~认识IUnitOfWork，为什么要出现IUnitOfWork接口第二讲 说说IUnitOfWork~Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事第三讲 说说IUnitOfWork~方法完整性与统一提交不冲突第四讲...
阅读全文
摘要：回到目录第一讲 认识IUnitOfWork，为什么要出现IUnitOfWork接口第二讲 Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事第三讲 方法完整性与统一提交不冲突第四讲 DbContext对象的创建应该向BLL层公开第五讲 我的IUnitOfWork+Repository架构 今天愉点时间，说说IUnitOfWork，它事实上是NHibernate上的东西，这里只是借一下它的思想，把咱们的EF和LinqToSql也优化一下，呵呵！对于IUnitOfWork它的中文是操作单元的意思，顾名思义，就是将多个操作放在一个单元中，把操作原子化
阅读全文
摘要：回到目录你是否真正了解TransactionScope？相关文章将不确定变为确定~transactionscope何时提升为分布式事务将不确定变为确定~transactionscope何时提升为分布式事务~续将不确定变为确定~transactionscope何时提升为分布式事务~再续（避免引起不必要的ＭＳＤＴＣ）一 了解事务选项，用它来控制嵌套事务 public enum TransactionScopeOption { //如果存在环境事务（我认为应该叫嵌套事务，氛围事务，ambient transaction），那么就加入其中， 如果不存在就创建新事...
阅读全文
摘要：最近在项目重构过程中，发现项目比较乱，项目中的类文件遍及了整个项目文件夹中，为此，我觉得有必要把它们整理一下，我的作法是：详细划分：BLL层：根据业务或者领域进行划分，如用户业务，财务业务，产品业务，其它业务等等。DAL层：根据表模块进行划分，我们在设计表时会根据功能为表加前缀，如User_XXX,Order_XXX,Product_XXX等等，所以，在DAL层对这些类文件进行最原始的功能划分，它可能有用户模块，公用模块，订单模块，产品模块，后台模块等等。如果你要划分，需要具备的条件：BLL层：一个业务领域专家，它需要对业务非常了解，经常它可能是项目经理人DAL层：一个底层架构师，它需要对数据
阅读全文
摘要：回到目录如果你想学好一样东西，一定要看高手是如何做的如果你想学好.net，一定要看.net framworks源代码如果你想学好分层结构，一定要去看petshop项目如果你想学好MVC，一定要去看dinner项目如果你想学好DDD，一定要去看Microsoft NLayerApp项目呵呵，今天主题是ＤＤＤ，所以，我们主要看一下NLayerApp的项目结构，在微软架构师开发一个项目时，他的心中一定对自己系统的架构很清晰，这时，他会使用一定工具把它的思想写出来，以便更好的让开发人员看到。表现层如图：分布层服务层如图：应用层如图：领域层如图：基础设施层如图：事实上，我们在设计一个系统时，从架构师的角
阅读全文
摘要：回到目录最近被ＤＤＤ吸引了阿，在这里感谢一下小佟，呵呵，领域驱动设计是个不错的东西，帮助我们把问题清晰化，这候对于复杂业务逻辑是很重要的，今天这一讲主要说一下ＤＤＤ中的基础设施层（Infrastructure）是如何被我实现的。Infrastructure Layer：主要功能是对领域模块进行持久化的，在这个层中你需要把领域对象序列化到指定的元件中，可能是数据库，文件或者内存对象，当然它也要提供从物理元件取出数据到领域模型的功能，这是对应的。目前的ＤＤＤ项目结果如下对于Infrastructure这个层我不去定义接口而是让它去实现Domain层的接口，即一切从领域出发，而Infrastruct
阅读全文
摘要：作为一名架构师，我们应该掌握哪些技术呢？占占简单来谈一下：面向对象OOP的理解，我是说理解，我不希望你告诉我百度里的概念！常用的数据结构，对于常见的数据结构，算法，应该知道一些！ＷＥＢ服务，对于分布式，大一点的项目都会遇到，你可以用WS，WCF，Remoting去实现它，它们的原理是你应该知道的，因为你是一名架构师，兄弟们都指着你呢，呵呵！全文检索：lucene.net，当然lucene只是实现全文检索的一种方式，你可以使用其它文件索引来干这事ＮＯＳＱＬ：你可以选用不同的开源项目，redis,memcached你会用一种就行了，呵呵缓存：cache，每个项目都会有自己的缓存机制，作为架构师的你
阅读全文
摘要：回到目录对于.net环境而言，日志的开源组件有很多，像Nlog，log4net等等，而我今天要介绍的是我的日志组件VLog，呵呵，事实上实现原理与作用都大同小异。作用：记录程序运行中的相关信息特点：提供了消息日志，错误日志，调试日志，警告日志，崩溃日志等等优势：提供了多种日志实现的方式，如SQL数据库，XML文本，WIN日志等等配置：它可以通过配置文件进行设置，提供了日志级别和记录方式等参数说明：VLog项目层次分明，一个接口，一个基类，5个实现的功能类，一切都是那么自然，下面看一下结构图：一个接口： 1 namespace VLog 2 { 3 /// 4 /// 日志操作...
阅读全文
摘要：这是一个系列，这是一个一看就叫人兴奋的东西，你的项目是否会有一些通用的核心组件，它在跨项目方面是否很方便，它在自身的扩展性上是否灵活，它的代码的优雅度是否有一个标准，它的代码是否严谨，这些将在这个系列中给大家进行介绍。AOP不是一个新东西，它对项目进行横向切割，它是对面向对象OOP的补充，对于通用的模块我们可以使用AOP的编程思想来干这事会比较好，世事上，在小微的世界里有很多牛X的开源项目都使用了AOP的思想，如orchard，注意我说的是思想，就是说，你，我，他所实现的AOP方式是不同的，这很容易理解。事实上，我们这个系列的文章主要是在讲Orchard Framework这个层次，下面看一下
阅读全文
摘要：回到目录很多时间之长，我写了EF架构~性能高效的批量操作(Insert篇），而今天我把Update篇也写一下，这对于批量处理数据很有帮助，它解决了EF与linq to sql批量更新数据上的效率问题。对于EF架构中的批量更新操作，需要我们为实体的导航属性进行手动的标示，因为EF生成的实体中没有一个特殊的说明，所以，我们必须要告诉系统，哪个属性是导航属性，而导航属性是我们不去进行update的。1 /// <summary>2 /// 属性的导航属性3 /// </summary>4 public class NavigationAttribute : Attrib...
阅读全文
摘要：回到目录相关文章将不确定变为确定~transactionscope何时提升为分布式事务将不确定变为确定~transactionscope何时提升为分布式事务~续将不确定变为确定~transactionscope何时提升为分布式事务~再续（避免引起不必要的ＭＳＤＴＣ） 对于frameworks的TransactionScope大家应该都很熟悉了，它是一个分布式事务的语句块，被包含起来的语句可以一起被提交，当出现异常后，统一进行回滚，这一切都是托管的。当ＷＥＢ服务器没有开启ＭＳＤＴＣ服务时，会出现这个提示：对于servers.msc中的ＭＳＤＴＣ服务，它经常性的被挂掉注意一下：如果你的msdtc服
阅读全文
摘要：回到目录事实是这样的,这个项目它有产品,用户,用户要买产品,这时产生了订单,而这三个对象都有被评论的功能,这时评论对象Review就产生了,我们要设计一个视图,它来实现对三个对象的评论功能,没有人会希望同样的功能被重复的开发,相同的代码出现的不同的地方,这当然也违背了DRY原则,所以,我们需要抽象,我们需要封装,我们需要对问题进行面向对象的分析. 第一部:将对象抽象出来,找来不变的与变化的属性 product,user,order共同作用于reviews,我们来看一下review的实体结构 1 /// <summary> 2 /// 评论对象 3 /// </summa...
阅读全文
摘要：在我们开始项目过程中，项目中通常会存在几个主要的对象，如你在设计“Ｂ２Ｃ”时，可能主要对象是“用户对象”，“产品对象”，“订单对象”，而这些对象的信息应该对我们来说是很重要的，当用户删除自己的产品时，我们可能不希望产品真的从数据库中被删除除，这时，我们在设计数据库时可能会把这几个对象所对应的表加上“状态”字段，即Status，它通常是int32类型的，而在程序中一般会对应一个枚举类型，你当然可以也叫它Status而今天要讲的GetModel()它只是本人封装的一个方法，它会在ＤＡＴＡ层出现，为每个带个Status属性的对象实现一个GetModel()方法，而这个方法中我们会过滤一些统一的条件，
阅读全文
摘要：当我们在开发过程中，遇到添加，编辑，删除等操作，这些操作对于数据库来都是成功的，所以在DATA层的CURD操作一般没有返回值，而对于业务层就不同的，我们需要将处理结果返回给WEB层，而如果DATA出现异常了，这时业务层要知道，并把结果进行处理，然后返回给WEB层，而返回的载体是我们要统一的，因为我们一个bool类型是不能满足要求的，它可以还会伴随其它信息，包括可能出现的实体完整信息。看看我的VMessage类，它有一个属性IsComplete，它的值由它内部的messageList集合控制，而这个集合如果没有信息，说明没有异常出现，IsComplete就是true，反之它为false,而我们可
阅读全文
摘要：再见了，Linq to SQL，我们会想念你的！从DBML文件中，我学到了太多的东西，不知道为什么微软在推出linq to sql后，不对它进行支持了，可能是一山不容二虎吧，entity frameworks的崛起不是偶然的，事实上在推出linq to sql之前，微软早就推出了自己的ＯＲＭ架构，即entity frameworks，有时我们叫它ＥＤＭＸ或者ＥＦ，它是幸运的，从发布１.０至今，一直是小微的宠儿，目前５.０已经出来了，给人的感觉就是操作简单，对它的插件支持比较多，由于使用了Ｔ４模板，所以扩展性非常方便，这可能是它对linq to sql胜出的一个原因，其次它还支持其它数据源，而l
阅读全文
摘要：回到目录无论是linq to sql 还是entity frameworks，在进行列表操作时都会有一个毛病，那就是它的操作只能一个实体一个实体的发到服务器，这样，如果列表的数量很大，如列表为１０万条数据，那么，这种操作将是非常性能的，可能你的ＤＢ就挂了。解决方案：拼接Ｔ—ＳＱＬ串，并使它具有通用性好处：与服务器建立一次连接，给服务器发一条ＳＱＬ命令，即可实现代码如下： 1 /// <summary> 2 /// 构建Insert语句串 3 /// 主键为自增时，如果主键值为0，我们将主键插入到SQL串中 4 /// </summary> 5...
阅读全文