用过许多的web开发框架,我是随着 Python这股热潮来参考的 web 开发方法 Django,之前也有使用过 Java 的 springMVC,RoR 框架。就着开发比较常见的几个问题,谈谈自己粗浅的看法。

结构:语言体系和开发习惯,Java 相对的定义都可以自己尽心约束和配置,完全可以按照自己公司的结构和习惯来编写,所以不存在什么灵活性一说。符合自己公司和团队的规范就好。Django也相对类似,对静态目录通过系统自带的os,path和setting配置可以指定相应的目录作为静态目录或文件的上传目录等类似的功能。在系统的功能规划方面,通过Django生成的工作目录会提供基础的程序,包括初始的wsgi,setting,url等项目基础文件之外,通过django manager startapp会在同级目录下生成相对应的app目录结构,整体来讲文件结构也普遍固定。RoR则依赖“约定大于配置“的信条把绝大部分的目录都规定的妥妥当当。做过类似开发的开发人员基本上都熟悉。完整的mvc目录结构,标准的public,static等都是按照通用的工程结构而来。

至于开发语言,单单讨论Java,Python,Ruby孰优孰劣完全没意义,不讨论,但Python那种强迫症的tab间隔习惯我很喜欢。

常用的开发场景

  • 自动化工具方面,随着Docker,Jenkins之类的工具推出。Java的自动部署和脚手架可以完全自己实现,但是就纯框架自带的功能而言,Django,RoR自带的脚手架确实比较优秀,Django可以通过脚手架自建工程、建立模块、通过模型创建数据库、建立数据库迁移任务。而RoR在这类功能基础之上还提供了一键远程部署、数据库版本回滚、
  • 开发流程和模板:RoR,Django都可以通过指令来生成模块代码,Java没有。Django开发中也封装了一些常用的ListView,DetailView,TemplateView来减少开发的代码量。生成完模块代码后,Django可以通过系统自带的Model层的定义在app中的admin.py通过@注册进入系统自带的后台管理中。不需要任何开发就可以实现web界面对数据的管理功能。这一点我相信是Django最强大也是最遭诟病的地方。优点在于不需要任何代码开发就可以把模型一件注入进入管理平台。只需要配置模型的字段就可实现模型的CURD,List页面的过滤查找。缺点是管理平台非常死板修改难度极大,比如要修改后台的模板风格、对模板变量添加一些常用的处理(比如把{{ temp }}从1替换成为”男”都需要编写代码来实现。)模板中不能使用Python的功能,需要符合模板的Api语法。Java,RoR则可以完全使用语言自带的功能,并且Java可以选择各类模板库作为自己的view展示层,但是他们都没有Django自带的实现需要自行开发。
  • 相关的插件之类:在这里的表现其实都挺不错的,相对来说可能Django,RoR更加的让开发人员“不用太想事儿“通过简单的配置就可以完成相关的功能,例如:分页、查询后参数保持的分页,防CSRF提交、CKEditor富文本编辑框、文件上传、图片切图等。相对而言,Django,RoR因为其插件方式,并且自带了相关的初始插件脚本。如:CKEditor通过pip install,bundle install之后,可以运行一个执行脚本,默认把相关的上传路径,上传的文件类型,图片的自动切图等相关配置通过脚本自动生成,更加省力而已。而Java的强项都是在系统架构方面,如:工作流模块、系统权限模块、数据缓存、分片、微服务等架构层级。所以就日常的业务代码开发而言Django,RoR的亲和力更好,开发中下规模的系统而言。Django,RoR更加具备优势。
  • API和测试:基本都差不多,swagger应该都会有相关的支持,至于测试我想Java应该更加优秀。本身就是一个庞大、繁杂的体系,定制化的自由度也更高。至于文件结构之类,那就是萝卜白菜的事也没有讨论的必要。

个人的感觉,其实Django的开发很尴尬,介于中间的位置。说全自动又没有Rails好,说定制程度和灵活性也没有Java好,我不太喜欢它的继承父类然后重写的方式。一开始都为了这个开发绕了好久,报错信息感觉也没有特别出彩。如果是纯选择开发web我应该还是会选择RoR。接下来就是个人的见解了,因为Python对于大数据、网络抓包、系统底层的服务编程更好。这也是相对RoR的优势。至于Java,嗨,世界第一还有什么好说的。以上是我作为一个完全没有接触过 Python 的萌新的使用体验。

推荐阅读:胡阳编写的 《Django企业开发实战高效Python Web框架指南》,完完整整的自己走一遍,相信每个人都会有自己的开发理解。

因为 Kaminari 使用的必须是 ActiveRecord 对象,一开始报了个错,半天搞不懂,回头自己重新查询了一下资料,其实官方的 Github 上就已经写好了。

把代码贴出来一下其实挺简单的:

def index
user_name
= params[:user_name]
tempSQL = "select o.*,u.user_name,u.nick_name,u.phone,f.title from
orders o, users u, flies f where o.user_id = u.id and o.goods_id = f.id"
if
!user_name.nil?
puts 'run here'
tempSQL += " and u.user_name = '#{user_name}'"
end
@orders
= Kaminari.paginate_array(Order.find_by_sql(tempSQL)).page(params[:page])
end

Kaminari.paginate_array 中已经就能够完成转换功能了,大家继续,玩得开心哦。

所见即所得编辑器想必是每个项目的必备品了,最近一直在捣腾的Rails3也有很好的支持。今天配置了一天的插件,死活不成功。终于在晚上大功告成。总结下经验无非也就这么几点。

  1. Rails 的版本 – KindEditor?0.3.11 支持的版本是 Rails 3.1 以及以上版本,对于低版本的用户,建议使用?v0.2.8 。并且最好使用插件形式安装,而非 Gem 形式。玩转了一大圈无非都是各种图片上传的问题。其中最大的原因就在于图片上传支持的组件有各式各样的问题。
  2. 对于的包是否齐全,如:paperclip
  3. 插件的放置地址是否正确。

如果是 Rails3.1+ 的朋友就非常简单了,添加编辑器也就简简单单的几个步骤,并且按照官方的做法是绝对没有任何问题的。

Rails3.1 + KindEditor 配置地址以及安装方法:

https://github.com/Macrow/rails_kindeditor

Rails 配置 Jquery 为默认JS框架之后是存在一些问题的。公共函数 Rails.js 中的某些方法完全无法支持了。解决方案如下。

  1. 修改配置文件,config/application.rb 去掉?config.action_view.javascript_expansions[:defaults] = %w(jquery rails) 前的#号。
  2. 删除Prototype,安装Jquery.js。
  3. 访问:https://github.com/rails/jquery-ujs/blob/master/src/rails.js
  4. 使用上述地址中的Rails.js替换原有项目的Rails.js。

Ruby版本:1.8.7

Rails版本: 3.0.5

Gem版本: 1.7.2

 

初次使用Rails完成项目,总体来说,MVC执行得非常到位。相对原来的Java确实省了不少功夫,但细看Rails框架,其实它能够做的东西,Java也有相应的工具能够协助完成工程的创建。

谈谈我的一些使用感觉:

1. 包依赖关系,这个是比较头疼的。在Java中,各类的jar包满天飞。自从有了manven工具之后,这类问题得到的很大的改善,相应的,Rails也有解决方案并且都是基于gem托管,非常方便,Rails3相对Rails2而言又有了更好的支持。直接通过修改工程根目录下的gem file就能够提供很好的支持。

2. 数据库迁移,这个就真不说了,特别适合我这样的DB新手。

3. 版本分离,通过一键部署以及相关的插件能够非常方便的进行数据库迁移,备份,版本发布。并且3个环境足够应付基本的项目开发需求。

4. 语法,比较松散,对写惯了Java的人员来说,适应还得需要一段时间,不过就目前来看,还不错。

5. JS,完全无法理解JS模版的概念,用起来感觉怪怪的。慢慢尝试看看。