软件开发架构知识体系个人积累Word格式文档下载.docx
- 文档编号:16170956
- 上传时间:2022-11-21
- 格式:DOCX
- 页数:70
- 大小:406.86KB
软件开发架构知识体系个人积累Word格式文档下载.docx
《软件开发架构知识体系个人积累Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《软件开发架构知识体系个人积累Word格式文档下载.docx(70页珍藏版)》请在冰豆网上搜索。
浏览器请求页,Asp.Net将确定是否需要分析和编译页,或者是否可以在不运行页的情况下发送页的缓存版本。
2.页面框架初始化Page.Init
Asp.Net在这个阶段开始创建页面,它产生你在.aspx页面里用标签定义的所有的控件。
此外,如果页面是一次回送(POST),Asp.Net将反序列化视图状态信息并把它们应用到所有控件上。
Page.Init事件被触发。
3.用户代码初始化Page.Load
不管页面是Get请求还是POST请求,Page.Load事件会被触发。
4.验证
在验证期间,将调用所有控件的Validate方法,此方法将设置各个验证控件和页面的IsValid属性。
5.事件处理
在这个阶段,页面已经被完全装载且通过验证,Asp.Net将会触发在上次回发后发生的所有事件。
6.呈现
在呈现之前,会针对该页和所有控件保存视图状态。
在呈现阶段中,会调用每个控件的Render方法。
在这个阶段,页面和控件对象任然可以用,因此可以执行一些最终步骤.
7.清除
在这个阶段,页面开始执行清除工作,并触发Page.UnLoad事件,此时页面对象虽然还可以使用,但是最终的HTML已经被呈现且不可以修改。
技能要求
前端
思想:
响应式布局、单页面应用、图标字体、MVVM、JS模块化、JS模板引擎
技术/框架:
HTML5、CSS3、LESS、Jquery、Bootstrap、Framework7
组件:
Webuploader、Ueditor/Umeditor、Highcharts、Jquery.dataTables、Jquery.form、Jquery.validate、Jquery.Jcrop、Jquery.mCustomScrollbar、Spectrum、Toastr、BlockUI、SuperSlide,还有一大堆小的Jquery插件就省略了
后端:
DDD(领域驱动设计)、TDD(测试驱动设计)、DI/AOP(依赖注入/面向切面编程)、模块化开发、异步编程、分布式架构、敏捷开发之SCRUM
AMVC5、C#5.0、EntityFramework6、xUnit+NSubstitute+Shouldly、aspnetboilerplate
工具:
Git、VS2013、SqlServer、MongoDB、Redis
开源组件:
AspNet.Identity、AutoMapper、Castle.Windsor、MiniProfiler
EmitMapper
权限验证、数据验证、异常处理、事务处理、数据转换等全在基础架构上完成,模块开发者不需要写这些代码。
2015-3-1616:
00补充:
本来想单独写一系列文章来分享abp框架,但今天有朋友问到,就提前补充分享一下,先发个git上的链接
顺便分享一些其他我认为有使用、学习和研究价值的项目:
Orchard的vNext版
html5页面的样板
EntityFramework的功能增强
非常短小精悍的后台任务组件
监测.NET后端和Web前端每一个步骤的耗时毫秒数,可查看EF生成的SQL
微信公众平台SDK的C#版,包括企业号的SDK
ORM
ALinq
、ORMLite、LinqtoSQL、EntityFramework
吐嘈
忙活了一个多月,XLinq总算"
能用"
了,BUG总算"
少点"
了,准备真正替代EF了,现在已经初步在自己的项目中使用了
EF这家伙,优点不少,缺点也不少,我就扯几个最让我头大的缺点(或许这里面的缺点是因为我不会用)
1.必须将所有实体一次写完整,不能通过DbContext.Set<
T>
方法动态加载实体
2.NoLock,硬伤啊,貌似就算用事务然后配置成ReadUncommited也不行
3.EF支持的LINQ各种坑,简单说几个
1..Where(x=>
x.LastLogin==DateTime.Now.Date),很简单很常用的代码么,但EF就是不支持
2..Where(x=>
x.Name==null),看起来好像没问题,但EF却翻译成了wherename=null,坑货
3.左连接!
不说实现左连接那郁闷的写法,郁闷的是EF不一定会给那种写法翻译成左连接
4.第三点吐嘈完毕
4.已删除
5.性能,其实性能这个好像也没那么差,测试过查询16万数据,近一百个字段,尼玛居然16秒就搞定了·
·
6.暂时想不起来
分享
吐嘈EF的人也不少了,我再这么就吐嘈两下完事的话有点没事找事·
所以,针对上面这些坑,我找了很多的ORM(其实好像也不多),试过alinq、,alinq不说,收费的,用不起·
后面这个的话,当时被坑多了,就没用过了,对了,还有SOD,大神深蓝医生写的·
然而我自己也曾写过支持LINQ的ORM,但那代码渣的够可以,不过总算写过,知道些原理,其实更多的是为了锻炼,毕竟要支持LINQ的话,难度是比较大的,所以这一次又再一次自己写,功能从简单起见,主要有以下功能
1.支持简单的LINQ查询,多表连接查询(不支持任意形式的嵌套查询)
LINQ一旦写复杂了,确实要生成高性能的SQL非常难,因为就算生成能执行的sql都比较难。
我更倾向于将业务拆分,变成简单的LINQ语句能完成的功能。
嵌套查询或许以后会支持,但到时候估计就是一堆坑
2.支持动态加载实体
不需要事先在DbContext里面把实体写好,事实上什么都不写都行,主要是为了便于封装数据层,否则的话我每添加一张表都不得不去DbContext里面加一个实体
3.支持在LINQ中调用方法和属性,例如.Where(x=>
Convert.ToBoolean(x.IsEnabled))
上面这个写法在EF中是绝对不支持的,另外还支持Date属性访问
4.多数据库支持
目前只支持了sqlite和sqlserver2008r2,应该说只要sqlserver2008r2支持了,那就可以部分支持其他sqlserver数据库了
5.支持自己编写翻译成sql的代码(未测试)
可以自定义生成自己想的sql
6.支持最小化配置,最小仅需要一个连接字符串
说这个我又要说java了,连helloworld都没跑起来却搞了三天的配置,多麻烦!
7.基本兼容EF的使用方法
降低学习成本
8.不需要查询,直接更新和删除数据
调用的方式和EntityFrameworkExnteded类似,这也算是EF的又一个硬伤
9.支持NOLock
10.其他我说漏掉的
使用方法
1.配置文件
这里只说最小化配置
2.建立数据库
我随便建的xlinq数据库,建了一个Users表,有两个字段,Id和Username,其中Id为自增并且是主键
3.建立实体
4.测试插入
终于到这儿了
怎么的,这跟EF的写法不是一模一样的?
运行结果:
5.测试查询
为什么要把插入放前面?
因为插入了之后才有数据查询
6.测试更新
更新有两种方法,先查询再更新和直接更新
第一种:
第二种:
7.测试删除
删除也有查询后删除和直接删除两种,这里只说直接删除
8.NOLOCK
后记
看着挺简单的基本功能,但做起来真是一把辛酸泪。
计划中还有性能测试的,不过先看有多少人关注吧!
如果想讨论与此相关技术或者索取源码,请进QQ群
74522853,答案XLinq
测试源码:
DTO
DTO即数据传输对象。
之前不明白有些框架中为什么要专门定义DTO来绑定表现层中的数据,为什么不能直接用实体模型呢,有了DTO同时还要维护DTO与Model之间的映射关系,多麻烦。
然后看了这篇文章中的讨论部分才恍然大悟。
摘两个比较有意义的段落。
表现层与应用层之间是通过数据传输对象(DTO)进行交互的,数据传输对象是没有行为的POCO对象,它
的目的只是为了对领域对象进行数据封装,实现层与层之间的数据传递。
为何不能直接将领域对象用于
数据传递?
因为领域对象更注重领域,而DTO更注重数据。
不仅如此,由于“富领域模型”的特点,这样
做会直接将领域对象的行为暴露给表现层。
需要了解的是,数据传输对象DTO本身并不是业务对象。
数据传输对象是根据UI的需求进行设计的,而不
是根据领域对象进行设计的。
比如,Customer领域对象可能会包含一些诸如FirstName,LastName,
Email,Address等信息。
但如果UI上不打算显示Address的信息,那么CustomerDTO中也无需包含这个
Address的数据
简单来说Model面向业务,我们是通过业务来定义Model的。
而DTO是面向界面UI,是通过UI的需求来定义的。
通过DTO我们实现了表现层与Model之间的解耦,表现层不引用Model,如果开发过程中我们的模型改变了,而界面没变,我们就只需要改Model而不需要去改表现层中的东西。
POCO
EntityFramework4的特性介绍可看这篇文章
.NET4中EntityFramework简介,其中最感兴趣的一点就是对POCO的支持了:
EF4为实体提供了简单传统CLR对象(PlainOldCLRObject/POCO)支持。
您的实体对象可以独立于EF存在,由此EF更好地支持了测试驱动开发(test-drivendevelopment)和领域驱动设计(domain-drivendesign)。
同时,EF仍旧可以帮助跟踪POCO实体的变化,允许延迟加载,也会自动修正对导航属性(navigationproperties)和外键的改动。
EntityFramework1.0发布了很长一段时间了,但感觉用的人很少。
其中一个很大的原因,也许就是不支持POCO,至少我自己是这么想而不使用EF1的,EntityFramework4.0版本(又称EFV2)将提供POCO支持,对很多人来说,这是开始使用EntityFramework的时候了。
学习最好的方式当然是动手练习了,今天花了大半天跟着这篇文章【翻译】在EntityFramework4.0中使用Repository和UnitofWork模式,这篇文章里头有3篇POCO的系列,虽然文章是写于EF4beta1的时候,现在已经是RC,一样有效:
POCOinEntityFramework:
Part1–TheExperience(【翻译】实体框架中的POCO支持-第一部分-体验
)
Part2–ComplexTypes,DeferredLoadingandExplicitLoading
(【翻译】实体框架中的POCO支持-第二部分-复杂类型,延迟装载和显式装载
Part3–ChangeTrackingwithPOCO
(【翻译】实体框架中的POCO支持-第三部分-POCO的变动跟踪)
还有这篇文章EF4–ImplementingPOCOObjects,图文并茂的详细介绍了整个过程。
这里整理一下学习过程中的注意点:
∙自动生成代码的功能要关掉
∙继承的ObjectContext的构造函数的参数其实就是指定数据库连接串ConnectionString
∙工具生成的Edmx的ConnectionString的只保存在该程序集的app.config中,记得拷贝到相关的app.config或者web.config
∙因为没有CSDL和SSDL,所以Edmx中的Model上的TableName和ColumnName务必和你的POCO的名称一致。
EntityFramework4.0引入了基于约定(convention)的映射,以允许不用显式的修饰,就可将实体类型,属性,复杂类型和关系映射到概念性模型。
一个简单的规则是,在你的POCO类中使用的实体类型名称,属性名称,和复杂类型名称必须匹配那些在概念性模型中定义了的相应名称。
∙代码的单元测试很重要
∙延迟加载的属性要设置成Virtual,ObjectContext上需要设置ContextOptions.LazyLoadingEnabled=
true
∙对于枚举类型的支持是通过复杂类型来实现的,可以参考文章
TDD
前言
最近团队要尝试TDD(测试驱动开发)的实践,很多人习惯了先代码后测试的流程,对于TDD总心存恐惧,认为没有代码的情况下写测试代码时被架空了,没法写下来,其实,根据个人实践经验,TDD并不可怕,还很可爱,只要你真正去实践了几十个测试用例之后,你会爱上这种开发方式的。
微软对于TDD的开发方式是大力支持和推荐的,新发布的VS2012的团队模板就是根据。
新的VisualStudio2012给我们带来了Fakes框架,这是一个针对代码测试时对测试的外界依赖(如数据库,文件等)进行模拟的Mock框架,用上了之后,我立即从Moq的阵营中叛变了^_^。
截止到写此文的时间,网上还没有一篇关于Fakes框架的文章(除了“VS11将拥有更好的单元测试工具和Fakes框架”这篇介绍性的之外),就让我们来慢慢摸索着用吧。
废话少说,下面我们就来一步一步的使用VisualStudio2012的Fakes框架来实战一把TDD。
需求说明
我们要做的是一个普通的用户注册中“检查用户名是否存在”的功能,需求如下:
1.用户名不能重复
2.可设置是否启用邮件激活,如果不启用邮件激活,则直接在“正式用户信息表”中检查,反之则还要进入“未激活用户信息表”中进行查询
项目结构
先分解一下项目的结构,还是传统的三层结构,从底层到上层:
1.Liuliu.Components.Tools:
通用工具组件
2.Liuliu.Components.Data:
通用数据访问组件,目前只定义了一个数据访问接口的通用基接口IRepository
3.Liuliu.Demo.Core.Models:
数据实体类,分两个模块,账户模块(Account)与通用模块(Common)
4.Liuliu.Demo.Core:
业务核心层,里面包含Business与DataAccess两个子层,DataAccess实现实体类的数据访问,Business层实现模块的业务逻辑,因为测试的过程中数据访问层的数据库实现会用Fakes框架来模拟,所以数据访问层只提供了接口,不提供实现,Business只调用了DataAccess的接口。
我们要做的工作就是用Fakes框架来模拟数据访问层,用TDD的方式来编写Business中的业务实现
5.Liuliu.Demo.Core.Business.UnitTest:
单元测试项目,存放着测试Business实现的测试用例。
6.Liuliu.Demo.Consoles:
用户操作控制台,功能实现后进行用户操作的UI项目
其他的项目与测试无关,略过。
开发准备
应用代码准备
Entity:
实体类的通用数据结构
1///<
summary>
2///数据实体类基类,定义数据库存储的数据结构的通用部分
3///<
/summary>
4publicabstractclassEntity
5{
6///<
7///编号
8///<
9publicintId{get;
set;
}
10
11///<
12///是否逻辑删除(相当于回收站,非物理删除)
13///<
14publicboolIsDelete{get;
15
16///<
17///添加时间
18///<
19publicDateTimeAddDate{get;
20}
IRepository:
通用数据访问接口,简单起见,只写了几个增删改查的接口
2///定义仓储模式中的数据标准操作,其实现类是仓储类型。
4///<
typeparamname="
TEntity"
>
要实现仓储的类型<
/typeparam>
5publicinterfaceIRepository<
TEntity>
whereTEntity:
Entity
6{
7#region公用方法
8
9///<
10///插入实体记录
12///<
paramname="
entity"
实体对象<
/param>
isSave"
是否执行保存<
14///<
returns>
操作影响的行数<
/returns>
15intInsert(TEntityentity,boolisSave=true);
16
17///<
18///删除实体记录
19///<
20///<
21///<
22///<
23intDelete(TEntityentity,boolisSave=true);
24
25///<
26///更新实体记录
27///<
28///<
29///<
30///<
31intUpdate(TEntityentity,boolisSave=true);
32
33///<
34///提交当前的UnitOfWork事务,作用与IUnitOfWork.Commit()相同。
35///<
36///<
提交事务影响的行数<
37intCommit();
38
39///<
40///查找指定编号的实体记录
41///<
42///<
id"
指定编号<
43///<
符合编号的记录,不存在返回null<
44TEntityGetById(objectid);
45
46///<
47///查找指定名称的实体记录,注意:
如实体无名称属性则不支持
48///<
49///<
name"
名称<
50///<
符合名称的记录,不存在则返回null<
51///<
exceptioncref="
NotSupporte
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 架构 知识 体系 个人 积累