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

时间总是过得很快,而我几乎没有时间来安安静静的写博客和完善文档。不过总算是框架在一直前进,而我的计划是在今年年底(公历)前,让此框架成熟稳定。

在很长一段时间里,我尝试了很多我之前没有接触的技术或者没用过的技术,比如knockoutJs、OData、T4等等,也许走了很多弯路,也许对框架作用并不大,但是却对我而言却很有价值。只有用过了才知道其可用程度和适用场景,没有使用过就没有发言权。

框架也在不断的重构,我不想照抄别人的路子,我只想做一款有特色的框架,安安静静编码,踏踏实实前进,怎么个特色法呢?如:

  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-08-25 02:19:13

Magicodes.NET框架之路——让Magicodes.NET帮你编写代码的相关文章

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

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

Magicodes.NET框架之路[转]

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

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

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

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

2015前端组件化框架之路

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

【转】前端组件化框架之路

1. 为什么组件化这么难做 Web应用的组件化是一个很复杂的话题. 在大型软件中,组件化是一种共识,它一方面提高了开发效率,另一方面降低了维护成本.但是在Web前端这个领域,并没有很通用的组件模式,因为缺少一个大家都能认同的实现方式,所以很多框架/库都实现了自己的组件化方式. 前端圈最热衷于造轮子了,没有哪个别的领域能出现这么混乱而欣欣向荣的景象.这一方面说明前端领域的创造力很旺盛,另一方面却说明了基础设施是不完善的. 我曾经有过这么一个类比,说明某种编程技术及其生态发展的几个阶段: 最初的时候

java计划任务调度框架quartz结合spring实现调度的配置实例代码分享

点击链接加入群[JavaEE(SSH+IntelliJIDE+Maven)]:http://jq.qq.com/?_wv=1027&k=L2rbHv 一:quartz简介 OpenSymphony 的Quartz提供了一个比较完美的任务调度解决方案. Quartz 是个开源的作业调度框架,定时调度器,为在 Java 应用程序中进行作业调度提供了简单却强大的机制. Quartz中有两个基本概念:作业和触发器.作业是能够调度的可执行任务,触发器提供了对作业的调度 二:quartz spring配置详

PhoneGap或者Cordova框架下实现Html5中JS调用Android原生代码

PhoneGap或者Cordova框架下实现Html5中JS调用Android原生代码 看看新闻网>看引擎>开源产品 0人收藏此文章, 发表于8小时前(2013-09-06 00:39) , 已有13次阅读 ,共0个评论 依照我一惯得套路,我会先说一点废话. PhoneGap和Cordova什么关系?为什么有的地方叫Cordova而有的地方叫PhoneGap ?PhoneGap是一款HTML5平台.通过它,开发商能够使用HTML.CSS及JavaScript来开发本地移动应用程序.因此,眼下开