准备开张一个新系统， 技术选型？

[bwangel]

现在如果要开发一个新系统，涉及到的有数据展示、客户管理、图表展现、事件通知等。应该是一种很常规的软件。
由我决定技术选型。主要是客户端的，现有几种方案：
1. WPF
微软推WPF似乎是失败了。完全没有如MS所说替换了Winform. 所以不想考虑。
此外WPF的美工不好招。

2. Winform
虽成熟但太普通，开发人员没激情，学不到新东西。

3. HTML5
好是好，但浏览器兼容性是个大问题。准备用Chrome内核外面套一个框子来“冒充”客户端软件。
再配合一个好的js框架，和服务端用webapi进行交互，应该不存在性能问题。而且招人是一抓一把。

目前我考虑的就这三种，当然还没有最终决定。各位有负责过类似方面的给点建议？

[wanghui0380]

其实呢，界面本身并不是问题。问题是设计者本身是否提供不依赖UI滴稳定滴，并且可以扩展滴中间api 你只要有这套api，其实界面选型什么滴随便你搞。甚至你可以同时上马 SL，html5，纯粹滴web，标准滴winfrom，IOS滴app 说到这问题我想提一下，我最近被公司派到另一家关联公司滴项目组去救火，项目完毕他们公司领导在最后一次庆功宴上单独找我聊了问我“什么我们这项目会有这么大滴麻烦，我们也分层啊，也DAL啊，我们也OO啊，为什么后期综合集成还这么大毛病” 我说“其实你原因很简单，所有api都是跟UI跑滴，不是跟逻辑跑滴，就连你们的分层，你们的DAL,你们的OO都是跟UI跑滴！界面上要个字段，就model里加个字段，然后DAL里加个sql。但是真正滴逻辑其实反而不见了，比如有这么一个地方需要根据一些N个用户选择项在去后端查找配置，最后确定一个价格，这么一个功能应该是一个内部维护，外部只有一个稳定接口滴逻辑把，结果呢你这项目不是，你这项目滴逻辑完全依赖UI滴，客户说我要多个选择条件，ok，你滴CS要逻辑要改，你滴BS逻辑要改，你滴安卓app还要同步修改逻辑” 上面说这么多其实就一个句话，请关心真正滴逻辑，请先提供稳定滴api，然后至于前台UI到真不是太过为难的事情，就是同时开始写bs，cs，app都只是看你公司有木有那么多闲钱去请那么多流水线UI实现人员罢了（cao版以前说胶水程序员，我不想这么说，姑且就叫流水线UI实现把，这些人不需要太高技术，只要有北鸟毕业滴水平，知道怎么实现ui，怎么调用后面的api就ok了）

[walkuere]

SWF C#等如何呢 如果你要频繁升级的，比如做词典，那么必须bs

[walkuere]

引用 20 楼 leo2003 的回复:

是公司内部用的系统， 还是卖给客户的系统？ 若内部用的系统，直接要求所有客户端都统一用的Chrome浏览器，不用再考滤兼容性， 直接做成B/S 这样不是更好。 若是我，就选择我最熟悉的Win Form .

为什么是chrome?

[wanghui0380]

在顺带说一下 在这个项目组里救火我最大滴感受是所有滴组员平时交流滴东西，基本都是不是项目逻辑，而是一些无伤大雅的技术，我影响比较深滴就是下面几句 A说：”选型错误啊，当初就应该SL，而不是html“ B说”SL，wpf不是被淘汰了么，还是html好，但是不该用easyui，应该用boost和jqui“ C说”别抱怨了，已经这样了，这个问题怎么办，客户说不行要加个按钮，这里数据展示要多加一列“ D说”加按钮你自己加吧，DAL里多加个方法，自己写个sql“ C说”别瞎扯，原始文档里没这个控制“ D回头说”额，原本没有么，那好把你多加个表，或者在C表里多加个字段。另外我跟你说D表里面有个字段我改约束了，变成联合主键了，因为UI变了，要求如此了“ B”额，兄弟又瞎搞了，我这边UI是跟你挂接滴，你联合主键了，我怎么办“ D”自己看着办把，另外头下通知说晚上加班，同步一下因为UI变动导致各个关联滴UI逻辑错误滴问题“

[以专业开发人员为伍]

工作年头比较多了以后，如果还是“整天下载点开源的东西学习，然后做项目经理”的，自己对核心技术的理解可能也就是那个习惯的层次，做的项目可能永远都是一样的。 根据你后边的描述，我不看好你们的项目。我觉得你可能还是用这个来练手。 我觉得既然都工作有些年头了，还是寻求突破吧，搞点真正的开发吧。别因循守旧。

[无聊找乐]

引用 23 楼 walkuere 的回复:

[quote=引用 20 楼 leo2003 的回复:] 是公司内部用的系统， 还是卖给客户的系统？ 若内部用的系统，直接要求所有客户端都统一用的Chrome浏览器，不用再考滤兼容性， 直接做成B/S 这样不是更好。 若是我，就选择我最熟悉的Win Form .

为什么是chrome? [/quote] 你那文章的内容 鼓吹 要爱“美国” 要把“中国”远远抛在后面，这是爱国言论？ 对于这样的帖子，你不管文章内容真实性就随声附和，声称中国没希望了，这也是爱国言论？ 碰到国内的腐败问题，不是想法去斗争，去改变，不是让国家社会变得更强大更美好，而是想着跑到美国去“爱美国”，让美国把中国远远的抛在后面，这不是汉奸卖国言论？

[chillystar]

如果能找到好美工，并且阁下团队充分了解WPF的话，做CS还是直接用WPF好，用户第一体验最重要，想想看，报表、图表动态展现动画过度，对用户而言是一种怎样的体验冲击？而且做出一个游戏级的APP界面是对产品非常有力的宣传；同时不存在兼容性问题，从xp到w8平板一个软件就能跑。 winform其实也并非太不如人意，只是做出来比较静态而已，但胜在熟悉，实现效率高，实施成本低。 WEB嵌入方式虽然也是一个办法，但成本也不是楼主想象中那么低： 首先美工也是必不可少的一个成本，好的html美工并不比wpf便宜到哪里去； 其次兼容性问题，虽然采用固定内核做单一兼容能解决目前； 三者不灵活，很多功能例如文件提交、展现本地图片或调用本地资源之类，就收到安全性制约，纵然能解决也牺牲了灵活性加大了消耗； 四则耗费资源，浏览器可不是省油的灯，稍微大点的界面处理可以卡得系统一愣一愣的，究其原因是因为浏览器是一种全加载再执行的机制； 五则内外交互性差，例如在外框架上实现了sockek如何交换将是很费劲的事情、再如阁下想从外框架访问WEB核心中某个document元素属性(特别那元素是一个object)，更是一个痛苦的事情，若用ie内核还可以通过结合mshtml组件进行访问，若用其他第三方则未必能解释的了； 最后就是开发和维护的复杂性，这种方式相当于同时开发cs和bs，若是技术分析下来或是应用扩展对两者依赖程度都很高，开发和维护成本都远远高于单一开发。 以上是个人一些看法，总的来说推荐如下：能有好WPF美工则上WPF；其次是Winform；万不得已不要考虑最后的方案。项目是效益，项目不是激情，更不是课堂。阁下负责一个项目，必须为效益为第一出发原则，例如眼前的经济效益和模块复用效益，而不是用来满足激情或是当实验品，请慎重。

[以专业开发人员为伍]

最后我想说一下所谓的“用web放到窗口里边冒充c/s客户端”的做法的一个失败的实例。 我们以前有一个团队做了一个所谓的IM，老板也是只图界面像IM，而项目经理也就是因为喜欢拿公司项目练手。大半年（也许是一年）之后拿出来了，让我们自己先用用，然后打算给用户使用。结果可想而知，这个漂亮的系统，原本以为可以给200人使用的系统（用户单位实际上坐办公室的有上千人），没过1周时间就被用户彻底否定了。 做web的人如果不懂得要达到c/s程序的性能、并发数量，就是自欺欺人的。而其看似美工制作得还可以的界面下，用户操作起来缓慢、不灵敏，这种问题还是其次。 主要还是桌面上这种“大地方”，跟手机那种“小地方”不同，桌面上的软件的要求操作方法丰富“例如鼠标拖拉、即时响应”。用web程序套一个c/s的外壳的人，作“死”了一个公司的项目之后，换个公司就不要再重复这种事情了。

[以专业开发人员为伍]

实际上想有教合理的性能、并发数量，你就先看看你们公司有没有自己开发的服务器系统，就行了。 如果做网页的人“一抓一把一把的”，那么就做点web OA程序管理管理“会议室预订、汽车预定、请假条批示”之类的就行了，就做一些管理查询界面就行了，就不要做更深入的产品，哪怕是复杂一点的模板承载的业务流程也做不好的。

[以专业开发人员为伍]

在web开发方面，我们可以采取c#（支持版本4语法，支持linq等等高级功能，也支持将Knockout、jQueryUI等的c#类库）编写大规模代码并且编译为javascript的方式，可以在我们的c#程序中直接调用各种javascript的漂亮图标框架和组件。因此开发web上的你所说的这类的东西不成问题。 但是当你说什么“外面套一个框子冒充客户端”时，这就有问题了。这就让人怀疑你们的团队的真正的实力在哪里，是否明知道自己的许多不会的东西而想极力隐瞒呢？是否真的能够开发好web应用程序程序呢？ 虽然你给出了一个“担心浏览器不兼容”的理由（这个理由根本不足以让人孤注一掷地去瞎搞），但是这个理由容易被理解为隐藏了更多的注定失败的因素。

[billidzc]

不错，有创意

[bwangel]

引用 13 楼 sp1234 的回复:

最后我想说一下所谓的“用web放到窗口里边冒充c/s客户端”的做法的一个失败的实例。 我们以前有一个团队做了一个所谓的IM，老板也是只图界面像IM，而项目经理也就是因为喜欢拿公司项目练手。大半年（也许是一年）之后拿出来了，让我们自己先用用，然后打算给用户使用。结果可想而知，这个漂亮的系统，原本以为可以给200人使用的系统（用户单位实际上坐办公室的有上千人），没过1周时间就被用户彻底否定了。 做web的人如果不懂得要达到c/s程序的性能、并发数量，就是自欺欺人的。而其看似美工制作得还可以的界面下，用户操作起来缓慢、不灵敏，这种问题还是其次。 主要还是桌面上这种“大地方”，跟手机那种“小地方”不同，桌面上的软件的要求操作方法丰富“例如鼠标拖拉、即时响应”。用web程序套一个c/s的外壳的人，作“死”了一个公司的项目之后，换个公司就不要再重复这种事情了。

我怀疑你这个案例的真实性，一个一年的项目也应该是个大项目了，就一般的规律来说，半年就应该有一个包括了核心功能的测试版本了，难道还发现不了性能问题？再者，如果是性能问题，凡是可怜的程序必有可恨之处，我观察过很多慢的“可怜”的程序都有很明显的性能BUG,很容易优化，发现性能问题后难道没可能优化？ 我也讲一个实例，刚刚经历过的，我们的一个产品网页需要在正文里加“热词”链接，结果应用起来以后卡得不行，后来检查了开发人员的 js代码，发现是用正则匹配的，我只给他简单提了一个建议，先用indexOf简单判断一下热词在正文里是否存在，再用正则，结果效率马上提交了几百倍。

[bwangel]

现在的套浏览器内核的项目也有很多成功案例了，而且在当前“移动先行”的大背景下，我相信浏览器+壳的方案还是有发展前途的

[大湿级]

Winform要好 公司做的系统都是winform做的

[by_封爱]

html5+nodejs

[zzyonepiece]

路过，wpf感觉漂亮！！！

[ktei2008]

引用 28 楼 bwangel 的回复:

现在的套浏览器内核的项目也有很多成功案例了，而且在当前“移动先行”的大背景下，我相信浏览器+壳的方案还是有发展前途的

参加了一个google的conference，有一个开发者展示了一款很酷的app，流畅华丽，并且android和ios版都有。最后那个开发者说:"sorry guys. You're all fooled. This app is actually HTML5！“。 所以关键不在选什么技术，主要是看你能把会用的技术做到多屌（没丝）

[gw6328]

wpf,最近几个项目都用wpf做的.

[bwangel]

引用 21 楼 wanghui0380 的回复:

其实呢，界面本身并不是问题。问题是设计者本身是否提供不依赖UI滴稳定滴，并且可以扩展滴中间api 你只要有这套api，其实界面选型什么滴随便你搞。甚至你可以同时上马 SL，html5，纯粹滴web，标准滴winfrom，IOS滴app 说到这问题我想提一下，我最近被公司派到另一家关联公司滴项目组去救火，项目完毕他们公司领导在最后一次庆功宴上单独找我聊了问我“什么我们这项目会有这么大滴麻烦，我们也分层啊，也DAL啊，我们也OO啊，为什么后期综合集成还这么大毛病” 我说“其实你原因很简单，所有api都是跟UI跑滴，不是跟逻辑跑滴，就连你们的分层，你们的DAL,你们的OO都是跟UI跑滴！界面上要个字段，就model里加个字段，然后DAL里加个sql。但是真正滴逻辑其实反而不见了，比如有这么一个地方需要根据一些N个用户选择项在去后端查找配置，最后确定一个价格，这么一个功能应该是一个内部维护，外部只有一个稳定接口滴逻辑把，结果呢你这项目不是，你这项目滴逻辑完全依赖UI滴，客户说我要多个选择条件，ok，你滴CS要逻辑要改，你滴BS逻辑要改，你滴安卓app还要同步修改逻辑” 上面说这么多其实就一个句话，请关心真正滴逻辑，请先提供稳定滴api，然后至于前台UI到真不是太过为难的事情，就是同时开始写bs，cs，app都只是看你公司有木有那么多闲钱去请那么多流水线UI实现人员罢了（cao版以前说胶水程序员，我不想这么说，姑且就叫流水线UI实现把，这些人不需要太高技术，只要有北鸟毕业滴水平，知道怎么实现ui，怎么调用后面的api就ok了）

你说的我不敢苟同，相反我认为业务逻辑比较好写，UI却往往是花精力最大的部分。

[五更琉璃]

LZ能把质疑都反驳回去，并且说的不错