Magicodes.NET框架之路[转]

  1. 插件式框架
  2. 响应式布局以及前后端对移动设备的支持
  3. 便捷的业务代码生成,比如CRUD生成,并且表单支持根据不同数据类型或特性生成相应的展示组件。
  4. 从框架到插件包括代码生成模板均走开源路线,便于理解和定制
  5. 一次开发多次使用:即纳入常用的业务插件、策略与模型(日志异常、支付策略、后台权限管理、CMS、流程引擎、微信平台、文档在线查看器等等)
  6. 多套前后端主题
  7. WebAPI & OData 的灵活接口
  8. 基于CodeFirst模式的数据访问,将数据结构更改纳入每一次代码迁移之中
  9. 开发人员面板

在此之前,非常感谢tjcccc和木宛城主对本项目的支持。

现在再来说下最近的些许事吧。

开源

代码已经两个月前不声不响的迁移到了GitHub,为什么是不声不响,因为我只想做一个安静的美男子默默地编码。这年头不会用Git的程序员肯定不是好程序员,我差点也落伍了,赶紧跟上。哈哈。 试了试还不错。

新的UI

官网UI已重新设计,并且购买了Ace bootstrap,在这里非常感谢tjcccc对本项目的贡献。

官网飞机票:http://www.magicodes.net/

设计师:tjcccc

后台UI:

贡献者:tjcccc

只是初具轮廓,东西还在不断地改,目前感觉Iframe用着不是很爽,可能整个后台UI会使用新的架构。~~~~

博客

博客设计稿已经出来了,表结构设计也基本完成,不过还没开始绑~~~

界面抢先看:

地址:http://www.magicodes.net/blogs

首席设计师:tjcccc

文档&文档查看器

文档?哎,又来催更啦!

文档已经编写了一部分,并会不断地进行完善。(PS:最悲剧的莫过于,当我写好一部分,发现这部分又被重构了)

之前打算将文档托管到OneDriver的Web Office App的,结果发现被墙了,于是~~

于是框架集成了一个文档查看器,便于在线查看文档。目前只实现了PDF查看器插件。

船票:http://www.magicodes.net/DocumentViewer?contentType=application/pdf&filePath=upload/Magicodes.NET%E6%A1%86%E6%9E%B6%E8%AF%B4%E6%98%8E%E6%96%87%E6%A1%A3.pdf

后面会考虑对接Web Office Web App Server以实现Office的在线打开与编辑。

后面会支持更多的文件类型,有兴趣的朋友帮搞搞吧~~~

数据丢失

这是一个沉重的话题,这年头没钱确实不好干事,虽然之前承诺了不删档测试,但是很不幸,因为回家办满月期间忘记了对香港服务器的续费,超过3天虚拟机被删除了!!!所以很抱歉的通知您,之前注册和登录的数据已经全部丢失。

代码生成

代码生成这块一直是我比较核心关心的问题,如何减少重复逻辑的业务开发,一直是我孜孜不倦的追求。那么Magicodes.NET现在已经可以生成简单的CRUD代码了~~

口号先响起:还在加班写代码?还在不断地重写业务逻辑?还在一个一个的打补丁?太Low了,让Magicodes.NET帮你来编写代码吧。凝聚Magicodes.NET团队的智慧,让Magicodes.NET帮您编写代码。

解决方案核心目录:

具体介绍请参阅:

不过我还没来得及写完,各位客户还是先看代码吧。T4生成这块我走了很多弯路,所以我决定在月底左右开始再次重构。先看看目前的成果:

配置View和控制器生成效果:

相关T4模板位置:

从控制器到UI均是代码生成哈,生成即用~~

刚才是配置生成,我们再看看CRUD生成:

这仅仅是起步尝试,再看一个:

我们再看看T4模板:

我们看看Users.tt的具体内容:

<#@ template debug="false" hostspecific="true" language="C#" #> 
<#@ output extension=".cshtml" encoding="utf-8" #> 
<#@ assembly name="$(TargetPath)" #> 
<#@ import namespace="Magicodes.Mvc.Default.Areas.Admin.Models" #> 
<#@ include file="$(SolutionDir)\T4\Magicodes.T4\ODataGrid\Header.tt" #> 
<# 
    ODataGridHelper oDataGridHelper=new ODataGridHelper(typeof(UserViewModel)); 
    oDataGridHelper.Params["_param_title"]="用户管理"; 
    oDataGridHelper.Params["_param_url"]="/odata/Users";  
    oDataGridHelper.Params["_param_addModel"]=JsonConvert.SerializeObject(new UserViewModel(){Id=Guid.NewGuid().ToString()});
#> 
<#@ include file="$(SolutionDir)\T4\Magicodes.T4\ODataGrid\Footer.tt" #>

可以看出,这里仅仅是传参而已~~

代码生成先告一段落吧,这里我进行了很多尝试,花费了很多精力,但是也体会到了很多。目前打算再挤挤时间重构下,下次见面时,T4代码生成将会更加惊艳。同时我也希望有兴趣的朋友Join with me!!

时间: 2024-11-01 18:44:42

Magicodes.NET框架之路[转]的相关文章

3.Magicodes.NET框架之路——预览(一)

3.Magicodes.NET框架之路——预览(一) 前言 一眨眼,已经过去两个多月了 ,哥已经火力全开了(业余时间和精力,甚至为此放弃了各种私活),所以大家不要抱怨慢哈.编程犹如逆水行舟,不进则退.这段时间,一方面是不断地重构和设计框架,另一方面也系统的学习了很多新技术,同时也感受到了其强大的生命力. 所以这两个多月,也感慨良多.两个多月的业余时间和精力,两个多月没玩LOL和CF,两个多月的全身心投入…… 现在本篇就重点说说架构这些事: 架构多次重构,甚至核心模块多次推倒重来. 架构已支持MV

Magicodes.NET框架之路——让代码再飞一会(ASP.NET Scaffolding)

首先感谢大家对Magicodes.NET框架的支持.就如我上篇所说,框架成熟可能至少还需要一年,毕竟个人力量实在有限.希望有兴趣的小伙伴能够加入我们并且给予贡献.同时有问题的小伙伴请不要在群里询问问题,QQ群仅限于技术交流. 所有有关Magicodes.NET的问题,请在此https://github.com/magicodes/Magicodes.NET/issues页面根据类型提交相应Issues.在使用Magicodes.NET之前,请先查看官方文档并且阅读FAQ(点此阅读). 上篇提到了

Magicodes.NET框架之路——产品之路(谈谈产品管理)

虽然Magicodes.NET现在还不属于产品,但是却不妨碍她想成为产品的心. 为什么突然有了此篇,这篇不是空穴来风,而是我思考良久的结果: 为了让大家知道我在干什么,我想干什么,我将要干什么还有我干了什么 为了让大家清楚Magicodes.NET的产品迭代 为了更好地收集以及管理Bug&需求 为了让我和大家清楚Magicodes.NET的方向 为了更好地团队协作,也为了将来团队的扩张 总之,基于这样或那样的原因,于是有了此篇. 本篇为个人想法与规划,希望和大家多多交流,共同成长. WorkTi

Magicodes.NET框架之路——让Magicodes.NET帮你编写代码

时间总是过得很快,而我几乎没有时间来安安静静的写博客和完善文档.不过总算是框架在一直前进,而我的计划是在今年年底(公历)前,让此框架成熟稳定. 在很长一段时间里,我尝试了很多我之前没有接触的技术或者没用过的技术,比如knockoutJs.OData.T4等等,也许走了很多弯路,也许对框架作用并不大,但是却对我而言却很有价值.只有用过了才知道其可用程度和适用场景,没有使用过就没有发言权. 框架也在不断的重构,我不想照抄别人的路子,我只想做一款有特色的框架,安安静静编码,踏踏实实前进,怎么个特色法呢

2015前端组件化框架之路

特别声明:本文转自@民工精髓的<2015前端组件化框架之路>.谢谢@民工精髓的分享!著作权归作者所有. 编辑推荐: 掘金是一个高质量的技术社区,从 CSS 到 Vue.js,性能优化到开源类库,让你不错过前端开发的每一个技术干货. 点击链接查看最新前端内容,或到各大应用市场搜索「 掘金」下载APP,技术干货尽在掌握中著作权归作者所有.商业转载请联系作者获得授权,非商业转载请注明出处.原文: http://www.w3cplus.com/components-in-webapp.html ? w

2. Magicodes框架之路——策略管理

闲话策略 策略,有很多解释.但鄙人个人比较看重这点: 策略,是为了实现某个目标或者针对某些问题而制定的应对方案,以最终实现目标.比如为实现生娃而XXOO. 因此在本框架中,策略(Strategy),则是为了实现某些功能或者处理某些特定问题而制定的通用方案或者规则.粗浅一点,你可以理解为XXOO这种方式,不管用啥姿势,归根到底都离不开活塞运动. 如果还不明白,我们举个文明点的例子,比如发送短信,这是系统中常用的功能,也许短信服务商有很多,实现发短信的方式也有很多,但是对于系统来说,只需要的是发送短

Magicodes框架之路——起航

前言 从事开发也好几年了,并且最近一直在做架构搭建的工作.这些时间,最大的感悟就是: 只有自己理解了的才是自己的. 对架构这块,若欲立之,必先破之. 故此,才准备利用业余时间来倾力打造这套框架.由于时间精力以及能力有限,也许这套框架初期会有很多不合理之处,但是我相信只要有恒心,这套框架迟早会打磨完美.由于本人秉承做一行爱一行的原则,对代码也比较痴迷,故此命名为"Magicodes框架". Magicodes ——意为"Magic Codes".代码就如同魔术,每一个

框架之路入门

按耐不住激动的心情,因为继上篇文章后,不断的完善框架,今天终于整个系统基本稳定了,就继续谈框架. 我做C#开发已经近五年了.已经爱上她了,我经常开玩笑说,写代码如同谈恋爱,关键是我想认真的做一名程序员而不是码农. 简单回顾一下,目前系统是WCF三层C/S插件系统.服务器端是WCF程序寄宿在IIS中,其中我的配置设计是长连接,客户端支持多线程,一个volatile的实例对象.客户端用Winform,其中客户端框架及规则及核心代码都是我实现编写的,顾今天只谈客户端. 什么是插件框架?一个插件是业务上

2015前端组件化框架之路(转)

https://github.com/xufei/blog/issues/19 1. 为什么组件化这么难做 Web应用的组件化是一个很复杂的话题. 在大型软件中,组件化是一种共识,它一方面提高了开发效率,另一方面降低了维护成本.但是在Web前端这个领域,并没有很通用的组件模式,因为缺少一个大家都能认同的实现方式,所以很多框架/库都实现了自己的组件化方式. 前端圈最热衷于造轮子了,没有哪个别的领域能出现这么混乱而欣欣向荣的景象.这一方面说明前端领域的创造力很旺盛,另一方面却说明了基础设施是不完善的