1
yueyoum 2015-04-05 21:17:19 +08:00
没用过 pyramid
按照LZ的描述, pyramid 也有 和django admin 一样好用的 admin ? |
2
yueyoum 2015-04-05 21:17:56 +08:00
django 现在带有 model migrate
我实在是找不到理由 不用 django 了 |
3
lianghui OP @yueyoum admin是什么玩意? 那种简单的数据管理ui? pyramid没有这种,只是个框。 对django了解不多。 主要用django做什么类型的业务呢,管理运营平台吗? 我知道django的model不适合特别复杂的业务。
|
4
crazyxin1988 2015-04-05 21:36:11 +08:00
有自由扩展到接口?
有木有和Flask那么多的实现的扩展啊? |
5
tini19 2015-04-05 21:49:18 +08:00 via Android
@lianghui 都有人敢用nosql做复杂业务逻辑,用django的orm有何担心。再说互联网时代不提倡复杂的数据库查询,复杂的逻辑部分用程序实现,数据库只做存储
|
6
lianghui OP @crazyxin1988 很少用到那些拓展,关键有比较好的接口和拓展接口。
|
9
est 2015-04-05 22:11:54 +08:00 via Android
pyramid 除了reddit 用一个老版本之外没人用咯吧?
|
10
yueyoum 2015-04-05 22:14:26 +08:00
@lianghui
> admin是什么玩意? 那种简单的数据管理ui? 那请你为你的项目做一个 admin, 不要太复杂, 达到django admin的程度就行。 权限管理,基本/多表关联 CURD,excel导入导出(借助第三方package),,, 你要多长时间? django 3分钟 > 主要用django做什么类型的业务呢,管理运营平台吗? disqus bitbucket > 我知道django的model不适合特别复杂的业务。 你知道的真的太少 |
11
tini19 2015-04-05 22:16:40 +08:00 via Android
最近发现v2ex上小白越来越多了
|
13
ryanking8215 2015-04-05 22:58:02 +08:00 via iPad 2
我用过pyramid和flask, 用在一个项目上,先用的pyramid后用的flask.
性能: 没有比对过两者性能,但两者应该在一个数量级,都是基于wsgi的,和tornado肯定不能比,你懂的。 路由: 都支持通过装饰器模式注册路由,都支持函数或者类注册路由 两者有区别,p将具体url记在一个字符串里,再用该字符串注册路由 Flask就直接用@app.get注册,或者用blueprint 模版 两者默认模版不同,废话!jinjia更流行,都支持第三方的模版, 另外,pyramid支持json的render,你只要返回dict就帮你生成json了,而且render是在装饰器里的,也就是你的应用只需要返回数据即可,flask需要显示调用render_template()函数,若要返回json你需要显示调用jsonify,我把它搞成和pyramid一样,用装饰器实现。当然这个区别也决定了单元测试的不同。 测试 Pyramid,无论你用什么模版,返回的是dict,所以你主要测试dict就行了,而且是针对注册的url的函数或类直接引用测试,而非通过具体的客户端环境测试。 Flask无法做到,需要测试真正得到的文本数据,因为它是在一个模拟的客户端请求上下文产生的。 项目比较小,而且是年前的,会有疏漏,ipad打字花了我半小时,希望对大家有帮助 |
14
lianghui OP @yueyoum 感谢指教。 前两年用过点django,不太清楚现在的情况怎样。基本现在自己造data-mapper模型,django现在分表支持好吗,如果按日需求分表分库。django自身的orm好使吗? 还有一个需求是django如果一些数据用mysql,一些数据模型落地是couchbase, es之类是否方便集成django的model?
django的admin是否适合直接给一个非技术的运营团对来管理业务? @tini19 orm是用的很多,可能你理解错了,如果你用nosql之类话,就和django的model说拜拜了,不过orm模式还是很不错了。不过现在做的用es, mongodb,couchbase,为了好维护基本直接data-mapper了 |
15
yueyoum 2015-04-07 10:23:12 +08:00
@lianghui
django orm 支持简单操作,复杂SQL django 文档里也推荐直接写 raw sql 现在有了 migrate, 直接在 RunSQL 里写 SQL ,就可以 分库分表,创建view,等等。 因为已经是 raw sql在干这些事情了。 sql模型之复杂,ORM是很难在 全部囊括 和 简单易用 之间平很好。 看 sqlalchemy 的复杂程度就知道。 django orm 就是 简单SQL任务,用orm提供的功能, 使用起来很简单。 复杂SQL任务,就别想着怎么用ORM去包裹了,直接raw sql完事。 一些 数据用 mysql,一些数据用其他 db 其他db肯定不能用 django model啊, 自己手写吧。 这部分 不是django model的问题, django model本来就是给 rdbms设计的。 我想你用pyramid一样得自己 处理其他东西。 我有个项目 django + mongodb, django models 肯定是没法用的。 自己用 pymongo/mongoengine 来搞就行。 你用了框架没有提供的功能, 不能说框架不好吧。 如果这样的话。 我能不能喷tornado? 连个高层次抽象的ORM(如同django orm, sqlalchemy)都不自带 |