高度封装的后端框架-简明ODOO回顾(一): 综述兼扫盲

前言

前些日子工作里得到一个机会,有机会接触一下odoo的学习和应用,现在将要告一段落,为了改掉狗熊掰棒子的习惯,准备写五六篇文章记录总结一下.这里是第一篇文章,就总体概述一下,主观性的东西会比较多,一家之言吧.

odoo来源

ODOO官网 ODOO历史
odoo是2002年一家比利时的公司推出的一个部分开源(社区版)的Erp产品,原来叫做openErp,8.0后新命名为Odoo.
odoo是一套python框架, 你能基于它快速开发出漂亮的财务,仓储,erp,人事等等功能,快速生成报表等.
个人觉得,odoo和其他任何框架相比,有一个思路上的区别:
别的框架: 优化开发步骤,封装后来技术细节,用户直接写业务代码
Odoo框架: 不仅仅封装了技术细节,还封装了大量的通用业务代码,用户可以基于这些现有的"半成品"继续开发代码

odoo优点

• 高度的封装,开发快速简便
• 已经有的通用业务逻辑,不需要从打地基开始造房子
• 优秀的软件设计原则,相比多数java框架,odoo实现了DDD(领域驱动)原则
• 优秀的addons(插件)机制
  • odoo中所有应用都是以插件形式存在
  • odoo插件可以像面相对象中的类一样实现封装,继承,多态
• 快速生成前端页面
• 快速开发,和java相比,odoo的开发效率是非长高的,个人觉得能到1:2

odoo 缺点

优点很多人说,但是缺点提的人少,但是一段时间体验下来,感觉缺点还是比较多的

• 学习成本,现在大部分公司用Java开发erp,那么从java转到python,从mysql转到postgreSql,从Vue转到JQuery都会有转型成本
• 前后端不分,想要分工成本就比较大(仅限14.0,15版还没学习)
• 前端交互比较弱,如果想要定制前端交互,写起来会比较吃力
• 生态比较弱,相比于java的非长丰富的免费的框架/工具/插件,odoo生态比较弱,而且好多都是收费的
• 大型化困难,我们和一些成熟的odoo服务商谈过这个问题,即使这些服务商,也不能提供很完美的odoo大型化的方案

适用条件

个人认为: 如果您的公司想要迅速的,低成本的开发一套企业应用,那就选ODOO吧
当然,您也应该有心里预期:

1. 不能提过多交互上的要求(但是odoo自带的前端界面也可以称作简洁漂亮了)
2. 难以大型化(单机->负载均衡->微服务->Set化,个人认为odoo只能做到第二层)

愿望

odoo用一套不同于其他框架的思路拼搏出现在的规模,帮python在Erp领域占有了很大一块领地,个人觉得还是很值得学习研究使用的.
如果将来我的雇主是个小公司,想要快速开发应用,我肯定会第一时间向老板推荐ODOO而非用java从头写起.
每个中国企业都希望做大做强,所以技术选型的时候特别喜欢考虑’前瞻性’,因此会付出很多没有必要的成本,个人觉得大多数企业更应该考虑类似ODOO的框架,简单快速低成本的开发您的应用.
希望odoo越发展越好.