随笔分类 - 架构设计
摘要：
相对于OSharp 3.0，3.3版本最大的更新，就是从框架级别定义了初始化流程，对初始化功能进行了抽象与封装，不依赖于第三方实现，第三方实现仅作为可替换的服务实现方案存在。
例如，依赖注入功能中，接口与其实现类的映射配置，对象容器的构建，对象的解析获取，都将通过框架定义的API来完成，而Autofac，仅作为这些功能的实现方存在，如果不想使用Autofac，则可以很方便的切换成别的IoC组件。
具体的初始化功能是怎样抽象与定义的，我们将在后续文章中逐个进行详解，这里先从整体来看看整个初始化过程是怎样的。
阅读全文
相对于OSharp 3.0，3.3版本最大的更新，就是从框架级别定义了初始化流程，对初始化功能进行了抽象与封装，不依赖于第三方实现，第三方实现仅作为可替换的服务实现方案存在。
例如，依赖注入功能中，接口与其实现类的映射配置，对象容器的构建，对象的解析获取，都将通过框架定义的API来完成，而Autofac，仅作为这些功能的实现方存在，如果不想使用Autofac，则可以很方便的切换成别的IoC组件。
具体的初始化功能是怎样抽象与定义的，我们将在后续文章中逐个进行详解，这里先从整体来看看整个初始化过程是怎样的。
阅读全文
摘要：
经过这段时间的发展，OSharp项目已经比较算比较成熟了，能看得过眼，算是拿得出手了，现在也重新提交到了github开源平台中，开源地址依然为：
https://github.com/i66soft/osharp
之前的旧版本，已经更名为osharp.v2，旧版本的地址为：https://github.com/i66soft/osharp.v2，请注意区分。
欢迎大家关注（Watch）、支持（Star）、参与（Fork）《OSharp快速开发框架》开源项目的发展。
阅读全文
经过这段时间的发展，OSharp项目已经比较算比较成熟了，能看得过眼，算是拿得出手了，现在也重新提交到了github开源平台中，开源地址依然为：
https://github.com/i66soft/osharp
之前的旧版本，已经更名为osharp.v2，旧版本的地址为：https://github.com/i66soft/osharp.v2，请注意区分。
欢迎大家关注（Watch）、支持（Star）、参与（Fork）《OSharp快速开发框架》开源项目的发展。
阅读全文
摘要：在日志开发中，有些日志记录需求是常规需要的，比如操作日志，数据变更日志，系统异常日志等，我们希望把这些常规需求都集成到OSharp框架当中。有了内置的支持，在做开发的时候，只需要很简单的配置，就可以实现相关需求。
关于三类日志，这里先简要描述一下：
操作日志：粗略描述系统用户（如管理员、业务人员、会员等）对系统的业务操作，只需要说清楚“XXX用户在XXX时间做了XXX操作”
数据日志：有时候，为了追溯用户的业务操作对系统产生的影响，需要记录数据变更细节，这就是数据日志
系统日志：主要记录系统在运行过程中产生的与业务无关的常规或异常的日志信息，这些日志信息通常由系统维护人员或开发人员查看
阅读全文
在日志开发中，有些日志记录需求是常规需要的，比如操作日志，数据变更日志，系统异常日志等，我们希望把这些常规需求都集成到OSharp框架当中。有了内置的支持，在做开发的时候，只需要很简单的配置，就可以实现相关需求。
关于三类日志，这里先简要描述一下：
操作日志：粗略描述系统用户（如管理员、业务人员、会员等）对系统的业务操作，只需要说清楚“XXX用户在XXX时间做了XXX操作”
数据日志：有时候，为了追溯用户的业务操作对系统产生的影响，需要记录数据变更细节，这就是数据日志
系统日志：主要记录系统在运行过程中产生的与业务无关的常规或异常的日志信息，这些日志信息通常由系统维护人员或开发人员查看
阅读全文
摘要：经过最近一段时间的努力，OSharp3.0新增了不少功能，如框架初始化流程，多数据库多上下文的支持，分类日志记录等，包含功能权限与数据权限的权限系统正在设计当中，基于实体配置的缓存系统，在计划当中。
从OSharp3.0开始，远离喧嚣的开源环境，由几个志同道合的小伙伴沉下心来，认真的去继续开发OSharp框架。做出变更如下：
OSharp3.0之前的源代码，仍然在github.com上面进行托管，但不再积极更新。
OSharp3.0及之后的源代码，仅在团队成员之间流通。
nuget 上面的类库，将持续更新，提供“非加密的dll类库文件，pdb调试文件，xml注释文件”的方式提供使用，有心人仍然可以通过各种途径很容易阅读到项目的源代码的。
配合OSharp3.0的新增功能，本系列博客将继续更新，对新增功能将会的详尽的技术描述，欢迎喜欢本系列的博友继续关注。
阅读全文
经过最近一段时间的努力，OSharp3.0新增了不少功能，如框架初始化流程，多数据库多上下文的支持，分类日志记录等，包含功能权限与数据权限的权限系统正在设计当中，基于实体配置的缓存系统，在计划当中。
从OSharp3.0开始，远离喧嚣的开源环境，由几个志同道合的小伙伴沉下心来，认真的去继续开发OSharp框架。做出变更如下：
OSharp3.0之前的源代码，仍然在github.com上面进行托管，但不再积极更新。
OSharp3.0及之后的源代码，仅在团队成员之间流通。
nuget 上面的类库，将持续更新，提供“非加密的dll类库文件，pdb调试文件，xml注释文件”的方式提供使用，有心人仍然可以通过各种途径很容易阅读到项目的源代码的。
配合OSharp3.0的新增功能，本系列博客将继续更新，对新增功能将会的详尽的技术描述，欢迎喜欢本系列的博友继续关注。
阅读全文
摘要：
日志记录对于一个系统而言，重要性不言而喻。日志记录功能在系统开发阶段，往往容易被忽略。因为开发阶段，程序可以调试，可以反复的运行以查找问题。但在系统进入正常的运行维护阶段，特别是在进行审计统计的时候，追踪问题的时候，在追溯责任的时候，在系统出错的时候等等场景中，日志记录才会显示出它不可替代的作用。记录的日志，平时看似累赘，只有在需要的时候，才会拍大腿后悔当初为什么不把日志记录得详细些。日志系统，是一个非常基础的系统，但由于需求的复杂性，各个场景需要的日志分类，来源，输出方式各有不同，日志系统又是一个相对复杂的系统。下面我们就来解说一下，OSharp开发框架的日志系统设计中，怎样来应对这些复杂性。
阅读全文
日志记录对于一个系统而言，重要性不言而喻。日志记录功能在系统开发阶段，往往容易被忽略。因为开发阶段，程序可以调试，可以反复的运行以查找问题。但在系统进入正常的运行维护阶段，特别是在进行审计统计的时候，追踪问题的时候，在追溯责任的时候，在系统出错的时候等等场景中，日志记录才会显示出它不可替代的作用。记录的日志，平时看似累赘，只有在需要的时候，才会拍大腿后悔当初为什么不把日志记录得详细些。日志系统，是一个非常基础的系统，但由于需求的复杂性，各个场景需要的日志分类，来源，输出方式各有不同，日志系统又是一个相对复杂的系统。下面我们就来解说一下，OSharp开发框架的日志系统设计中，怎样来应对这些复杂性。
阅读全文
摘要：
数据层设计真是一个百说不厌的话题，大系统说并发量，说高性能；小系统追求开发效率，易维护性各有各的追求。
OSharp 开发框架的定位是中小系统， 数据层的开发效率与易用性的权重就比较高了，所以，使用ORM当然是首选。在 .net 环境下，有众多的闭源的开源的优秀的ORM组件，从各方便对比来看，EntityFramework 是不二之选。一提起 EntityFramework，不少同学又要蠢蠢欲动来吐槽其性能了。其实，经过几个版本的更新换代，现在的稳定版 EntityFramework 6 已经相当好用了，nuget 上截止到目前 “8,830,918 total downloads” 已经足够能说明问题了，EntityFramework 在整个 .net 世界是相当受欢迎的。不过，不管哪个技术平台，能不能用好一个技术与技术水平有很大的关系，如果没追求，随处的 select * from
阅读全文
数据层设计真是一个百说不厌的话题，大系统说并发量，说高性能；小系统追求开发效率，易维护性各有各的追求。
OSharp 开发框架的定位是中小系统， 数据层的开发效率与易用性的权重就比较高了，所以，使用ORM当然是首选。在 .net 环境下，有众多的闭源的开源的优秀的ORM组件，从各方便对比来看，EntityFramework 是不二之选。一提起 EntityFramework，不少同学又要蠢蠢欲动来吐槽其性能了。其实，经过几个版本的更新换代，现在的稳定版 EntityFramework 6 已经相当好用了，nuget 上截止到目前 “8,830,918 total downloads” 已经足够能说明问题了，EntityFramework 在整个 .net 世界是相当受欢迎的。不过，不管哪个技术平台，能不能用好一个技术与技术水平有很大的关系，如果没追求，随处的 select * from
阅读全文
摘要：
一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。
OSharp开发框架约定的分层方案，依然是传统的三层（数据层 - 业务层 - 展现层）分层方式，但也有自己的特点：使用了三层分层方式，但并不严格遵守传统三层的“各层职责极其分明”的约定；参考了“领域驱动设计”的一些思想，但为了保证性能，并不使用 DDD 的聚合模型。
阅读全文
一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。
OSharp开发框架约定的分层方案，依然是传统的三层（数据层 - 业务层 - 展现层）分层方式，但也有自己的特点：使用了三层分层方式，但并不严格遵守传统三层的“各层职责极其分明”的约定；参考了“领域驱动设计”的一些思想，但为了保证性能，并不使用 DDD 的聚合模型。
阅读全文
摘要：OSharp是一个依赖于EntityFramework，专注于业务数据模型与EntityFramework解耦的适用于中小型项目开发的（插件式）框架。OSharp将支持基于OSGi.NET的插件式开发，但我们还是会从非插件式讲起，详细了解OSharp开发框架的方方面面。在本系列中，将会讲解到不少非常实用的技术与编码技巧，欢迎关注。
阅读全文
OSharp是一个依赖于EntityFramework，专注于业务数据模型与EntityFramework解耦的适用于中小型项目开发的（插件式）框架。OSharp将支持基于OSGi.NET的插件式开发，但我们还是会从非插件式讲起，详细了解OSharp开发框架的方方面面。在本系列中，将会讲解到不少非常实用的技术与编码技巧，欢迎关注。
阅读全文
摘要：前言 最近在整理EntityFramework数据更新的代码，颇有体会，觉得有分享的价值，于是记录下来，让需要的人少走些弯路也是好的。 为方便起见，先创建一个控制台工程，使用using(var db = new DataContext)的形式来一步一步讲解EF数据更新的可能会遇到的问题及对应的解...
阅读全文
摘要：前言 今天我们来谈谈EF的缓存问题。 缓存对于一个系统来说至关重要，但是是EF到版本6了仍然没有见到有支持查询结果缓存机制的迹象。EF4开始会把查询语句编译成存储过程缓存在Sql Server中，据说EF6中对此做了改进，会把Linq To Entities 的查询条件直接编译缓存在EF中。但是...
阅读全文
摘要：前言 首先对大家表示抱歉，这个系列已经将近一个月没有更新了，相信大家等本篇更新都等得快失望了。实在没办法，由于本人水平有限，写篇博客基本上要大半天的时间，最近实在是抽不出这么长段的空闲时间来写。另外也是一直没想好本篇应该怎样写比较容易理解，于是就一天一天的拖着了。废话不多说，言归正传。 EF的C...
阅读全文
摘要：前言 经过前面EF的《第一篇》与《第二篇》，我们的数据层功能已经较为完善了，但有不少代码相似度较高，比如负责实体映射的 EntityConfiguration，负责仓储操作的IEntityRepository与EntityRepository。而且每添加一个实体类型，就要手动去添加一套相应的代码，也
阅读全文
摘要：前言 经过EF的《第一篇》，我们已经把数据访问层基本搭建起来了，但并没有涉及实体关系。实体关系对于一个数据库系统来说至关重要，而且EF的各个实体之间的联系，实体之间的协作，联合查询等也都依赖于这些实体关系。实体映射 实体与数据库的映射可以通过DataAnnotation与FluentAPI两种方...
阅读全文
摘要：前言 终于到EF了，实在不好意思，最近有点忙，本篇离上一篇发布已经一个多星期了，工作中的小迭代告一段落，终于有点时间来继续我们的架构设计了，在这里先对大家表示歉意。 其实这段时间我并不是把这个系列给忘记了，而是一直在思考，想着接下来应该怎么写。因为园子里已经有很多非常优秀的EF的文章了，比如：E...
阅读全文
摘要：前言 在《上篇》中，基本的项目结构已经搭建起来了，但是有个问题，层与层之间虽然使用了接口进行隔离，但实例化接口的时候，还引入了接口实现类的依赖。如下图： 面向接口编程，Controller应该只依赖于站点业务层的接口，而不能依赖于具体的实现，否则，就违背了在层之间设置接口的初衷了。 另外，如果...
阅读全文
摘要：前言 在《上篇》中，已经把项目整体结构规划做了个大概的规划。在本文中，将使用代码的方式来一一解说各个层次。由于要搭建一个基本完整的结构，可能文章会比较长。另外，本系列主要出于实用的目的，因而并不会严格按照传统的三层那样进行非常明确的层次职能划分。需求说明 在本系列中，为方便大家理解，将以一个账户...
阅读全文
摘要：系列导航MVC实用架构设计（〇）——总体设计MVC实用架构设计（一）——项目结构搭建MVC实用架构设计（二）——使用MEF应用IOCMVC实用架构设计（三）——EF-Code First(1)：Repository，UnitOfWork，DbContextMVC实用架构设计（三）——EF-Code ...
阅读全文
