@googlebot #134 你用 c 好高贵哦，v2ex 这里那么多用 IDE 开发的太 low 了，你最好赶紧离开，不要再来，省得待久了说我们把你变 low 了

MFC 是 C++类的形式封装 windows 的 API，还一口一个 C 的设计器，都令人怀疑是不是用过。delegate observer 是现在主流语言的共性，.net 的 Event 就是用委托机制实现的，一知半解没用过几天 C#就敢来比较。张口闭口真编译伪编译，搞得好像只有原生编译才是名门正派，其他都是歪门邪道，小心 JAVA/Python/PHP Coder 来喷死你。

Vs 戏称宇宙最强 IDE 不是随便说说的。编译器、配套工具、IDE 功能界面、开发文档等等都是尽力为开发者着想，.net 框架、c#也是业界大师精心设计。苹果在手机、电脑、app store 上挣了那么多，可是却对开发者一点不上心，开发工具 bug 一堆，文档写得烂，swift 语言改来改去，感觉没想好就发一个版本出来了

换个 logo 的 iphone

要扩大影响还是去微博

看了原文，我看这个人只有一句话是对的，yunos 将变成一个符号，我觉得是省略号，lol

有这个需求？马化腾和张小龙会哭吗？😭

Fat32 可以支持 7gb 的文件？

感觉都是烫手山芋不想要的样子，lol

这个营销活动的思路很奇葩，限量抢购一个不能试用的，配置低没关系，好歹给个直接能用的

估计是 sdk 卸载了，vs 修复或 vs 镜像里找 sdk 安装

若每种支付一张表，按用户查询所有支付数据就必须关联所有支付表，实质效果就是一张大表，还不如全部支付明细存在一张表，还减少了关联呢，而且要是增加支付方式，要关联更多的表，相关 sql 也都要改，维护也很麻烦。

小米 5s 拍照很好，im378，2000 多，性价比很高，给喜欢旅行拍照的老妈买的，使用反馈非常不错

基本功能没做好，其他的体验卖点都是白搭

这种情况直接在微博上怼，顺带嘲讽一下阿里不管那么多骗子假货不管，偏偏盯上一个卖二手的，at 淘宝、咸鱼、chanel，再 at 几家大众媒体

Word excel web 版不是很方便么，多人协作，版本管理都有

匹配表里用随机函数 select 2 个用户进行匹配，然后从匹配表中删除，这个过程作为一个事务，也就具有排他性了。像楼上所说，考虑扩展功能，需要放在表中，redis 相比之下就无法满足需求了。要说性能，pg 也是很强的。

注册登录不需要模板，因为只有一个。其他实体的增删改查是类似的话，可以用模板方法。将原来实体对象的字段作为元数据存到一个表，包含唯一标识、字段名、长度、数据类型等，实体数据都存到一个业务表，包含实体数据标识、元数据标识和值，根据业务需要，可能要在元数据表或业务数据表增加字段用来条件查询或分组统计，例如表单 id、时间、操作用户等。当需要操作该实体时，可以在各功能的 controller 中读取相应的元数据和业务数据，由 view 对数据在前端控制，例如数字字段只能输入数字，为 HTML 内容提供一个 HTML 编辑器等，提交数据在 controller 做统一安全校验，然后做业务校验。

模板用统一方式的操作实体，可以减少前端工作量，但缺陷有 3 个：1、物理模型和逻辑模型不一致，如果文档不完善，后期运维会有很大问题，所有业务数据是混杂在一个表里的，不知道业务逻辑根本无法筛查出所需数据。2、所有业务数据存在一个表里，在数据量达到千万或存储达到 TB 性能将遇到明显的瓶颈，若 sql 写得不好，索引优化不当，可能几十万数据就会有性能问题，预计 3-5 年到不了性能瓶颈可以忽略，3-5 年使用后一般会有较多改动需求，可以到时再调整架构重构代码。3、同类功能处理不同实体，如果业务相差很多，就得在一个 controller 写大量不同的业务逻辑，这是很糟糕的情况，所以要预先分析，一个模板只操作相似的，少量的不同可以在 controller 处理。要是你各个实体的业务差别都很大，做成模板反而是得不偿失的，不仅没有一致的实体模型，代码可维护性也不高。

模板方式有利有弊，最好评估一下是否有这样的必要。

这个不建议做在一个 view，现有 12 个表，每个 4-5 个 viewmodel，要改成只做在一个 view 里面，那在这个 view 处理的数据可能非常多，后期运维会很麻烦，建议根据业务逻辑适当划分成几个模板，逻辑上会比较清晰，维护也会比较方便