应用程序框架实战二十七: 基于Mvc+EasyUi+EF+Autofac的CRUD DEMO免费发放,纯干货,附截图

  不知不觉,这个系列已经写了好几十篇了。我本来打算把基础介绍完再发放Demo进行整体说明,不过大部分人更喜欢看得见摸得着的表现层,对后端不是太感兴趣,所以我决定先发一个简单的CRUD Demo出来,让大家先感受一下,被应用程序框架封装之后的代码大体是什么样子。

  采用EasyUi作为前端框架,主要是它比Dwz强大,另外也是基于Html扩展,比更强大的Ext要简单得多,更重要的是它越来越流行了,对于更详细的决择或前端架构设计,我会在后续文章说明。

  虽然是一个简单的单表CRUD操作,但是分层架构和各方面的封装都已经到位,和你随便下载的Demo是有本质区别的。当然,我没有加入一些重要的框架特性,比如日志跟踪、全局异常捕获、权限控制等内容,待我讲解到那些内容时再进行更新。

  关于版权,本系列发放的任何源码,均允许免费使用,可用于商业目的。由于本系列博客更新进度慢于发出的源码,所以在本系列文章未贴出相关代码之前,不允许你将代码贴到你的博客,另外转载请注明出处。

  如果本系列文章讲解的内容超出已发放源码的范围,我会发放一个新版本,请留意。

  另外,如果你发现代码里面的BUG,请告知,我会尽快修复。

  首先发几张VS解决方案截图。Demo共分两个解决方案,一个是应用程序框架项目Util,,另一个是项目解决方案Applications.Managements。

下面是DEMO运行起来的效果截图。

再来看几张Mvc视图代码的截图。

  可以看到,EasyUi已经被封装到Html扩展上,Api设计主要参考了Ext.Net,至于前端框架为何需要封装,以及如何封装,我会在后续文章详细讲解。

  另一方面,你会发现代码中几乎看不见JS,所有EasyUi相关的JS已经完全抽出来,并运用了约定胜于配置的原则,如果你遵循框架的模式,你不需要进行任何配置和JS操作,就可以完成基本功能。

  为了提升易用性,还在表格中增加了右键菜单,当然这是出于演示目的,对于一般的模块没有多大用处。

  下面看控制器和应用层服务代码的截图。

  从截图上可以看出,对于简单的CRUD操作,基本没你什么事,基类帮你把大部分工作都已经做完了,当配合代码生成器时,你可以把绝大部分时间腾出来搞业务逻辑,而不是这些机械工作。

  下面是封装的EasyUi Js代码截图。

  最后再贴几张框架代码截图。

  为了让你能够运行起来,我还提供了一个数据库备份,是基于Sql Server 2005的,在Data目录中,大致有10000行随机生成的数据。

  源码是免费的,但不会轻松让你下载到,要拿源码,你只需干两件事,一点推荐,二在评论中留下你的Email,我这样做也是为了增加一点人气,没人看,我写文也没有多少激情。

  当然,我不可能随时24小时为你服务,我每次发放源码限时1天,超过1天请等下一次,本次截止2015年1月22日中午12点,超过不再发放。

  很多代码还没有讲到,比如Ioc等,就自己先看看吧,我后续文章会对开发要点和框架设计的细节详细说明。

  我将不定期发放最新源码,请关注。

  .Net应用程序框架交流QQ群: 386092459,欢迎有兴趣的朋友加入讨论。

  谢谢大家的持续关注,我的博客地址:http://www.cnblogs.com/xiadao521/

时间: 2024-10-10 00:32:08

应用程序框架实战二十七: 基于Mvc+EasyUi+EF+Autofac的CRUD DEMO免费发放,纯干货,附截图的相关文章

应用程序框架实战二十三:基础查询扩展

上面两篇已经作好准备,本文将进行基础查询扩展.当使用了Entity Framework这样的ORM框架以后,我们查询的核心被集中在IQueryable的Where方法上. 如果UI需要通过姓名查询一个客户,会在UI上放置一个输入框作为客户姓名的查询条件.服务端接收以后通过Where方法进行过滤,如下所示,entities表示DbContext的子类. var queryable = entities.Customers.Where( t => t.Name == name ); 当然,也可以使用

应用程序框架实战二十六:查询对象

信息系统的查询需求千变万化,在仓储中为每个查询需求创建一个特殊方法,将导致大量乏味而臃肿的接口. 一种更加可行的办法是,在应用层服务中描述查询需求,并通过仓储执行查询. 为了能够更好的描述查询需求,可以将查询功能从仓储中抽取出来,专门创建一个查询对象. 查询最复杂的部分是条件过滤,这也是查询对象的主要职责.查询对象可以认为是规约模式的一个变种,允许查询对象动态创建查询条件. 在Util.Domains项目Repositories目录中,创建查询对象基接口IQueryBase,代码如下. usin

应用程序框架实战二十五:查询条件(规约模式应用)

前面已经做了一些准备工作,本篇将介绍查询条件的封装,它是规约模式的一个应用. 规约使用一个对象来封装谓词,我之前已经介绍过它在验证方面的应用,本篇是规约模式在查询方面的应用. 规约的强大之处在于,能够将一堆杂乱无章的条件判断或查询条件封装起来,以一个清晰的概念来表达,并使得这些谓词具备了可复用的能力. 首先在Util.Domains项目的Repositories目录中创建ICriteria接口,这个接口表示一个查询条件,代码如下. using System; using System.Linq.

应用程序框架实战二十四:基础查询扩展 - 分页与排序

上一篇介绍了IQueryable的Where方法存在的问题,并扩展了一个名为Filter的过滤方法,它是Where方法的增强版.本篇将介绍查询的另一个重要主题——分页与排序. 对于任何一个信息系统,查询都需要分页,因为不可能直接返回表中的所有数据. 如果直接使用原始的Ado.Net,我们可以编写一个通用分页存储过程来进行分页查询,然后通过一个DataTable返回给业务层.不过进入Entity Framework时代,分页变得异常简单,通过Skip和Take两个方法配合就可以完成任务. 为了让分

应用程序框架实战二十:映射层超类型

上一篇介绍了工作单元层超类型的封装演化过程,本文将介绍对Entity Framework映射层超类型的封装. 使用Entity Framework一般需要映射三种类型的对象,即实体.聚合.值对象. 聚合与实体映射的主要区别是:聚合映射单属性标识Id,并需要映射乐观离线锁Version,而实体的标识往往需要映射成复合属性,这样方便物理删除聚合中的实体.Entity Framework通过EntityTypeConfiguration进行实体映射. 值对象以嵌入值模式映射,这需要使用ComplexT

应用程序框架实战二十一:DDD分层架构之仓储(介绍篇)

前面已经介绍过Entity Framework的工作单元和映射层超类型的封装,从本文开始,将逐步介绍仓储以及对查询的扩展支持. 什么是仓储 仓储表示聚合的集合. 仓储所表现出来的集合外观,仅仅是一种模拟,除了测试以外,没有理由使用内存中真正的集合来创建仓储. 不应该为所有实体建立仓储,只有聚合才拥有仓储. 仓储用来重建已持久化的聚合,而工厂用于新建聚合. 使用仓储的优点 直接使用Entity Framework的DbContext不是很好吗,为什么还要在DbContext的上方封装一层仓储呢,这

应用程序框架实战二:十年前的回忆

大约10年前,我刚刚步入.Net开发,那时候还很流行单层架构,直接在界面上拖控件,然后绑定数据.数据库操作使用原生的Ado.Net,每次都要创建数据库连接,打开连接,发送Sql,获取结果.关闭连接.每当我需要进行数据库操作的时候,就把这一段复制粘贴过去,就这样干了几个月. 一日,一位师兄给我介绍了名为SqlHelper的数据库辅助类,使用了这玩意以后,我发现开发效率和质量倍增.由于不需要来回复制粘贴,冗余代码变少,代码简洁很多.另外不需要手工关闭数据库连接,也让BUG变得更少.虽然SqlHelp

【WePY小程序框架实战四】-使用async&await异步请求数据

[WePY小程序框架实战一]-创建项目 [WePY小程序框架实战二]-页面结构 [WePY小程序框架实战三]-组件传值 async await 是对promise的近一步优化,既解决了promise链式then的这种写法壁垒,又让异步请求更像同步,若对async await不太了解的同学可以直接参考阮一峰老师的文章async 函数的含义和用法,这里我们只关注怎么在小程序wepy架构中如何使用. 依赖库 import 'wepy-async-function' app.wpy中启用 export

应用程序框架实战十五:DDD分层架构之领域实体(验证篇)

在应用程序框架实战十四:DDD分层架构之领域实体(基础篇)一文中,我介绍了领域实体的基础,包括标识.相等性比较.输出实体状态等.本文将介绍领域实体的一个核心内容——验证,它是应用程序健壮性的基石.为了完成领域实体的验证,我们在前面已经准备好了验证公共操作类和异常公共操作类. .Net提供的DataAnnotations验证方法非常强大,Mvc会自动将DataAnnotations特性转换为客户端Js验证,从而提升了用户体验.但是客户端验证是靠不住的,因为很容易绕开界面向服务端提交数据,所以服务端