首先 java 并非一切皆对象。所以这个题目本身就是建立在错误前提下的假命题。

@shyling 没说你什么都不会，但你肯定不会 django 。不要以为看了 djangobook 之类的入门教材就叫会 django 了。你其实连 django 的门槛都还没进入，因为真正的 django 代码都不是这种入门教材里那么写的

@crazycookie 确实 django 在传统 request response 的 app 开发上已经远远领先其竞争对手了。只可惜当初因为 rails 比较火，导致 rails 本身有些盲目膨胀的自信，而其它框架也盲目仿造 rails ，以至于 rails 和其模仿者都没有意识到 django 在 1.4 以后已经在设计理念上远远把它们甩开了距离。

@shyling python 装饰器当然是有功能的，它立刻改变了被装饰的对象。

两者除了看上去相似，功能上完全不同。 java 的注解只是注解，它本身不改变被注解对象的行为和性质，只有理解这些注解的处理器才会改变行为。而 python 的装饰器会改变被装饰的对象的行为和性质。所以 python 装饰器比 java 注解更强大。

@shyling 对于不会用 django 的人来说，你还是一边用 ssh 一边黑 django 吧

@crazycookie 事实上比 rails 还快。很多习惯 rails 风格的程序员都有些井底之蛙的感觉

不要用 putty ， putty 在 linux 下字体难看，又难用。直接用 shell 。如果需要管理链接的话可以安装 SecPanel

我个人感觉 django 的设计思路甩 rails 和仿 rails 框架几条街。当然框架本身是否优秀是一回事，你自己熟悉哪个又是另一回事。

如果你的 angular 模板里大量依赖 django 模板的渲染，那说明你使用这个组合的方式错了。 angular 应该只管前端，所有数据都应该通过 service 向 django 发起 webservice 请求。

变量不存在继承一说。在当前模板里一个变量有就有，没有就没有。

@zmrenwu 你可以自己看在 github 上最新的代码： https://github.com/django-crispy-forms/django-crispy-forms/blob/dev/crispy_forms/templates/bootstrap3/inputs.html

我使用的是 1.6.0 ，是最近的发行版，也没有看到会渲染 row

比如什么默认样式是你不想要的？ crispy form 渲染的默认样式一般根本不存在什么问题。所以我不明白你觉得不需要的样式是什么

@slixurd 纯属稻草人论据。没有支持 spatial 的扩展，难道你还自己造一个轮子？你自己造的轮子有官方 spatial 扩展高效吗？即使你有这样的能力，现在现实就是需要立刻实现计算距离，你觉得让楼主从 0 开始的可能性多大？

楼上所有的回答要么是馊主意要么是回答不到点子上。

你要高效地做这种对 Spatial 数据的查询，你应该安装一个支持 spatial 的数据库及其扩展，例如 postgres 是对 spatial 支持最好的数据库。其次你创建的数据库必须是一个 spatial 数据库。然后你就要用扩展 sql 来做查询。一些 web 框架如 django 有对 spatial 数据库非常好的支持。

中国的劳动法总体来说是对雇员有利的。显然楼主对国外的劳动法的美好愿景只是出于想象。

不使用外建，说明你没有用类的观点来审视你数据库的设计，一般这会导致你到后期才注意到表设计的不合理

@caixiexin 准确地说这是一种现代 java 模式设计 practice 。如果你有兴趣，有可以搜索到很多表达支持这种 practice 的文章。我来说说为什么我认为对自己生命周期无知的 pojo 是一种更好的设计模式的原因。

首先来了解一下 java 设计模式的演变。最初 java 程序员确实是使用对自己生命周期无知的 pojo 类的，也可以说这是一种无设计模式的设计模式。一个类调用另一个类的方法往往是 new 一个 instance ，然后调用新 instance 的方法。但是很快有人注意到这种方式在当时硬件条件下的缺陷，即在多线程模式下，多个做同样事情的 instance 会占用更多的内存，于是在那个时期诞生了很多著名（或者说臭名昭注）的设计模式，最出名的莫过于这种用 private constructor 管理自己生命周期以达到 singleton 的设计模式。

但是现在 java 界又返璞归珍到原先的 pojo 了。为什么？我认为有这些原因

1. private constructor 其实产生了代码冗余。它们想实现一种模式，但是为了实现它，每个这种模式的类都在一遍又一遍地重复代码

2. 由于 constructor 是 private 的，在做单元测试时无法 mock 依赖类。显然在该设计模式产生的年代，单元测试并不被重视。但是现在不同了，单元测试是决定设计模式是否合理的最重要标准

3. 随着注入依赖这一设计模式的产生， pojo 之间的依赖关系变得更加容易管理，从而使得管理自己生命周期的做法变得毫无意义