用Nodejs多嵌入式有一段时间了。本人原是做python的，现在打算全面转nodejs，所以现在需要在项目中使用靠谱的mvc框架和orm框架。我在网上找了很多，发现现在nodejs还没有具有绝对优势的框架，可选的框架很多，所以请使用过的同学帮忙评价一下，使用哪个比较靠谱：
类MVC的框架： sails geddy 我现在感觉做的比较全面的就这两了个， sails基于express我比较倾向，但是实现完整度来说还是geddy比较好。
ORM：上面提到的框架都有自己的ORM实现，另外成熟的ORM框架还有 orm2 sequelizejs persistencejs 他们基本的功能都实现了，包括关联，nosql的支持，个人感觉sequelizejs实现的较完整。
毕竟还没有实践过，所以打算请教一下用过的同学们，哪个比较好？
web方面，如果不想让设备被玩残的话，那就不要用express系的框架，不要用任何基于http的框架，node.js的web框架在安全方面一塌糊涂。对于小设备来说，我更倾向于采用nginx + websocket的组合来搭建网站，确切的说，是nginx + socket.io。涉及到设备间通讯的时候，再加上一个socket.io-client。不使用任何http get/post之类的方法，一定要彻底防止内存或tmp分区被爆
orm方面，我不建议使用，毕竟设备不是PC，资源有限，写数据的速度和功耗也很糟糕，对存储的访问需要非常克制。用json已经足够了，平时作为内存里的js对象，需要存储的时候做个JSON.stringify(obj)，保存成文件，就足够了。
感谢您的回复。我的问题没有问清楚，造成了误解，在嵌入式中使用nodejs已经有一段时间了，这块自然是不会使用什么框架的，而且我们处理都是串口信息。我现在要在网站项目中使用nodejs了（我本人也是做网站开发的），所以在想要使用什么框架，所以我的问题的环境是正常的服务器环境的，不是嵌入式设备。
compound: mvc + orm 加上比较完整脚手架rails构建体系
orm2: 不倾向于分开选择orm和mvc，那不是意味着要自己做或者在选择一套脚手架。
bookshelf: orm，著名的ghost博客系统使用的backbone+promise形态的orm，这个是最近偶尔看到，不用的原因跟上面orm2差不多
sails: 比较新一代的mvc框架，思想体现为前后分离，直接从数据库到上层接口一次性生成。但是我们当时项目开始的时候发现没有联合查询，所以直接放弃了，但是现在看来根本也没什么太多的联合查询的需求。
geddy: 我就不知道了，看起来感觉一般啊
Meteor: 勇敢者游戏，超级新概念框架，超牛逼，看Star就知道了，他们服务器端的设计是完全脱离程序级别的，是非常高级抽象。
Derby: 跟meteor类似，不过弱了很多，其实sails的概念就是Meteor和Derby概念的一半。Derby依赖的他们自己实现的racer项目就跟sails感觉类似，
我们最后选择了用compound框架，好处是开发起来快，因为rails体系大家比较熟，单元测试集成测试什么都生成的差不多了。坏处是他们的mysql-adapter不是很好，主要是主键不支持字符串，我们自己改了改。
如果让我重新选择，我可能会选择sails，看过他们源代码，很精巧，安全也做得不错。
我现在在做BPO方面的开发，用的是 nginx + socket.io + redis + knockout.js ，没有用框架，除了少数存档数据外几乎没有用数据库，一切为了性能。当然这不符合一般的应用需求。
@wenbob
socket.io性能真的也一般，虽然我们自己也用。 redis抛开持久化的能力跟memcached比起来性能也有差距，而且集群化做的也不久。 knockout.js就不用说了，backbone, angularjs, emberjs应该都比ko好多了吧，至少我从2007年开始玩微软wpf/silverlight/mvvm体系，看knockout还是觉得很淡疼。还有就是knockout做RIA内存泄漏比较严重啊。
所以性能快慢只是一个相对概念，我们团队自己也是用socket.io+redis做聊天集群的，清楚现有系统的负载上线和准备好扩充方案也是必须的。
@runawaygo 如果只使用websocket做传输，socket.io性能是可以接受的，测试性能上看和直接用websocket相当。至于说redis和memcached，呵呵，真有什么差距吗，况且这玩意和集群没什么关系。集群是应用架构的事，不要被工具束缚，我就拿redis来当读写缓存的。
我这边没有复杂架构，就是用websocket集群做动态数据的传输，用nginx集群做静态http传输，用redis做动态数据的缓存，用json文件做不常写数据的存储，用mongodb做查询数据的存储。当然，集群的概念是由应用决定的，不是底层工具定的。
ko是做浏览器端模板的，用在单页面应用里，没有发生过什么内存泄漏，最主要的是，兼容性好，从IE6到安卓手机通杀。用ko的另一个原因是界面设计的工作彻底独立出来了，我们的后端只是接收socket.emit命令，返回json的简单tcp服务，不涉及任何界面和交互方面的元素。
我们的应用场景里，通过socket.io传输的动态数据远远少于通过nginx传输的图片文件，瓶颈始终不在后端，只要nginx集群伺候好了，后端性能从来就不是问题，以至于感受不到你所说的性能一般。
@wenbob 我没有说你用的不行或不好，我的意思是你所谓的为了性能有点一厢情愿。视图逻辑分离是个mvc框架都会做，因为这就是前端组建分离的意义所在。至于兼容性，一个webapp从ie6兼容到android是有多分裂。真的需要这样吗？
@runawaygo 并不是这样的——视图逻辑分离是个mvc框架都会做，但是这远远不够。大部分MVC框架都是偏重于码农的，对设计师而言就是个怪物——尤其是在设计外包的情况下。我不认为在浏览器上做router是个很光彩的事。MVC用在浏览器里本身就是中了后端码农思维的传统毒害。就我公司的应用场合，因为是商业应用，必须对浏览器有好的支持。我们选择了websocket和flashsocket，性能和兼容性都兼顾了，而且客户接受。继续我的观点，性能主要靠nginx，而不是后端代码。只要不是做实时语音视频或者网游之类的应用，socket.io后端就不会遇到瓶颈。
@ssr66994053 对普通的应用还是可以的，我不是说express不如别的node web框架安全，而是说这些都不安全 :D 是从设备角度来看待的，在有限内存的设备上，只能选择那些资源消耗绝对可控的框架，这个要求对服务器来说不存在，对嵌入设备来说就是必须的。
@wenbob 我觉得你错的地方是你认为mvc是从后端演化过来的，你认为后端的mvc才是mvc的原本。 所以建议你看一下Martin Flower在2004-2006年完成的一系列文章，GUI Architect。 当然你也可以看一下MVC起源在Smalltalk-80版本上大概是什么组织关系。
angular, knockout, ember都是属于偏重模板驱动的，view first的概念 backbone，javascriptMVC偏重于控制器驱动，controller/presenter first的概念
性能我之前都说了，性能是相对概念，所以不要把“一切为了性能”挂在嘴边。