随笔分类 -  系统架构设计

摘要：原则对于任何一项技术实现来说都是至关重要的，在设计某一个系统功能的时候我们讲究的是设计原则： 【单一职责原则Single Responsibility Principle、里氏替换原则Liskov Substitution Principle、依赖倒置原则Dependence Inversion Principle、接口隔离原则Interface Segregation Principle、迪米特法则Law Of Demeter、开闭原则Open Close Principle】。 在架构设计的时候我们也讲究架构原则： 阅读全文

摘要：最近在研究DDD颇有收获，所以整理出来跟大家分享，共同进步！ 我们在设计业务系统的时候都会存在一个非常棘手而又无法回避的问题“业务扩展性”、“业务灵活性、”面向对象化“，尽管我们熟练掌握设计思想、设计模式、设计原则等等关于如何设计灵活性的系统设计理论，但是我们似乎都没有将它们运用到真正业务系统设计、开发当中去，为什么？这样的疑问如果对有心想设计好系统的朋友来说肯定是很早就出现过，只是无法解决，因为我们目前使用的设计方法是与面向对象设计背道而驰的。 阅读全文

摘要：这个主题扯的可能有点远，但是它关系着整个LINQ框架的设计结构，至少在我还没有搞懂LINQ的本意之前，在我脑海里一直频频出现这样的模型，这些模型帮助我理解LINQ的设计原理。其实在最早接触环路模型和碎片化模型是在前两个月，那个时候有幸接触企业应用架构方面的知识，里面就有很多业务碎片化的设计技巧。其实理解这些所谓的设计模型后将大大开阔我们的眼界，毕竟研究框架是要研究它的设计原理，它的存在必然是为了解决某一类问题，问题驱动它的设计模型。所以我们在研究这样的模型的时候其实已经在不知不觉的理解问题的本质。 阅读全文

摘要：在开始看本篇文章之前先允许我打断一下各位的兴致。其实这篇文章本来是没有打算加“开篇介绍”这一小节的，后来想想还是有必要反馈一下读者的意见。经过前三篇文章的详细讲解，我们基本上对LINQ框架的构成原理有了一个根本的认识，包括对它的设计模型、对象的模型等，知道LINQ的查询表达式其实是C#之上的语法糖，不过这个糖确实不错，很方便很及时，又对一系列的LINQ支撑原理进行了大片理论的介绍，不知道效果如何； 阅读全文

摘要：到了这里我们似乎隐隐约约的能看见LINQ的原理，它不是空中花园，它是有基础的。在上面的一系列新特性的支持下，微软通过大面积的构建扩展方法使得上述特性能连贯的互相作用，形成自然的集成查询框架。上面的这些特性都属于语言为了LINQ而做的增强，也可以说是设计者们在不断的探索新的比较符合现代开发体系的语言特性，也越来越多的支持函数式的编程特性，比如DLR的引入对Python、Ruby函数式脚本语言的强大支持，后面也会越来越多的支持其他的函数式脚本语 阅读全文

摘要：LINQ简称语言集成查询，设计的目的是为了解决在.NET平台上进行统一的数据查询。 微软最初的设计目的是为了解决对象/关系映射的解决方案，通过简单的使用类似T-SQL的语法进行数据实体的查询和操作。不过好的东西最终都能良性的发展演化，变成了如今.NET平台上强大的统一数据源查询接口。 我们可以使用LINQ查询内存中的对象(LINQ to Object)、数据库(LINQ to SQL)、XML文档(LINQ to XML)，还有更多的自定义数据源。 阅读全文

摘要：在本人的.NET面向上下文、AOP架构模式（概述）一文中，我们大概了解了上下文如何辅助对象在运行时的管理。在很多时候我们急需在运行时能把对象控制在一定的逻辑范围内，在必要的时候能让他们体现出集中化的概念，如人群、车辆、动物等等。而Context与AOP有着密切的联系，Context表示逻辑抽象的范围而AOP描述了在这个逻辑范围内如何进行控制。其实这两者都是设计模式外的设计模式，与具体的技术实现无关。[王清培版权所有，转载请给出署名] 阅读全文

摘要：上下文：其实就是一个逻辑上的业务、功能区域。在这个逻辑区域里可以有效的进行管理，算是一种制度的约束，也可以理解为某种范围类的数据共享。 其实在很多应用框架中到处可以看见上下文的概念，包括.NET本身的设计就建立在这种思想上的。实例化的对象默认存在于系统中的默认上下文中，我们可以构建自己的上下文将对象在运行时进行合理的管理。 在ASP.NET框架中比较经典的就是HttpContext上下文对象。所有的运行时对象都..... 阅读全文

摘要：前段时间一直在学习和研究.NET事务处理，慢慢的我发现可以使用事务处理来实现一种可逆的系统框架。这种框架在一些IT社区似乎还没有见过，但是在我们日常开发中确实有这个需求。所以我花了点时间深入的研究了一下事务的原理和使用，实现了以事务为纽带，以资源为操作对象的可逆框架。 这里我假设您对事务有了整体的认识，也对自定义事务管理器有过了解。[王清培版权所有，转载请给出署名] 阅读全文

摘要：最近一边参与公司的项目开发，一边还肩负着基础库的创建和维护。真真切切的体会到写框架的不容易，写出好的，方便使用的框架更不容易，需要考虑的东西太多，需要掌握的东西太多。不过不要紧我们正在前进的道路上。同志们一起加油！ 最近在使用存储过程的时候总觉得有点麻烦，尽管在前期对ORM和统一数据源接口封装已经下了很多功夫，对IDataParameter之类的接口已经进行了很好的封装，但是还是觉得麻烦。[王清培版权所有，转载请给出署名] 经过与DBA的沟通，他认为对存储过程的封装是有必要的，以他十几年的经验看，存储过程后期的移植是必不可少的。现在的项目是用SQLSERVER2008开发的，后期可能会移植到ORACLE上去，那么对存储过程的编写DBA考虑很周全。但是对于程序员来说，经验稍微丰富点的可能会通过某种工厂将具体对 阅读全文

摘要：这篇文章讨论的概念其实比较简单的，但是在实际的项目应用中非常的重要和普遍。 我们的项目一般都是采用分层架构，有的三层有的可能五层或者其他的方式组织系统的架构，但是始终要将系统的架构按照模式设计，我们才能重用和接受维护。 随着ORM的流行和大面积的使用，行业内出现各种各样的ORM框架，有自己开发的有大型的软件公司开发的，基本在使用上都遵循了以实体为中心的概念，也就是围绕关系数据库中的表为操作对象。复杂的可能还包括连接查询多表操作等等。[王清培版权所有，转载请给出署名] 按照分层架构设计中的指导约束，我们应该尽可能的在系统模块之间采用Entity进行数据的传递。当然世事无绝对特殊性的项目可能没有这么简单 阅读全文