考虑转技术方向，大牛给点建议

[圣殿骑士18]

我现在项目上做的管理信息系统，采用的是有C端的web架构系统，由以下技术组成：
C端：winform+devexpress
B端：webapi2.0 + ef6 + ef extend
数据库：mysql5.6

但现在越来越感觉，离主流技术方向越远，问题越多。主要有两个大的问题：
1、使用C端写非设备相关的管理系统的不方便。
之前一直采用C端，是因为有硬件控制方面需求的原因，有些界面需要使用winform或者windows service，为了追求使用体验，索性全部做成C端架构。
不是C端写管理系统就不好，我当初选择用C端写管理系统，说服自己的一个理由就是操作效率高于bs系统。现在的C端我采用Model + 数据绑定 + CodeSmith模板，配置一个CRUD模块也非常快，C端也没什么业务逻辑，它就是一个“View”。 但在现在的移动互联网时代，手机上，pad上要运行管理系统，即使B端不变，我还得再写一套网页上的View。想想一个功能要写多套View，还要考虑它们之间的兼容性，也是很烦的事情。
2、ef的性能问题
我花了几个月时间，深入研究了ef，对于数据批量操作，我引入了ef extend，已经将ef的性能发挥到了极致。但性能仍然会有损失，比如ef extend生成的sql，虽然不再需要ef先提取数据，再更新数据库，但它生成的sql是嵌套sql，即生成一个结果集，再作为表关联进行更新。比如：

UPDATE in_changelist AS j0 INNER JOIN (
SELECT
1 AS `C1`, 
`Extent1`.`TaskNo`, 
`Extent1`.`ItemCode`
FROM `in_changelist` AS `Extent1`
 WHERE (`Extent1`.`TaskNo` = 'T2016082201') AND (`Extent1`.`ItemCode` IN ( '00000001A000300078000001','00000001A000300078000003' ))
) AS j1 ON (j0.TaskNo = j1.TaskNo AND j0.ItemCode = j1.ItemCode) 
 SET 
SpaceCode = 'R1'

从执行效率上来说，它仍然需要两次数据库遍历，即先select出结果集，再关联update，而且如果中间结果集大的话，因为无法利用索引的问题，可能会使性能大幅降低。
我也相信对于一般的信息系统，哪怕是ERP来说，也足够使用了。但它却没法满足我的新需求：把后端迁移到云上。做成云端系统，意味着硬件成本不再是客户自己承担，而变成了显性成本，直接体现在了软件价格上。如果实现同样的用户数支持，使用ef投入的云端费用要增加一倍的话，那是个巨大的成本，这将直接导致定价提高，降低产品的竞争力。

对于以上的两个重要问题，我实在想不到有什么好的解决办法，所以考虑直接放弃这个架构，转向bs和更轻量级的ORM：
前端：使用angularjs+bootstrap
后端：mvc5+dapper

大牛们给点建议

[圣殿骑士18]

引用 8 楼 sp1234 的回复:

[quote=引用 楼主 daixf_csdn 的回复:] 我也相信对于一般的信息系统，哪怕是ERP来说，也足够使用了。但它却没法满足我的新需求：把后端迁移到云上。做成云端系统，意味着硬件成本不再是客户自己承担，而变成了显性成本，直接体现在了软件价格上。如果实现同样的用户数支持，使用ef投入的云端费用要增加一倍的话，那是个巨大的成本，这将直接导致定价提高，降低产品的竞争力。

就算是你从你的EF的某个查询sql语句推导出“服务器端的性能降低一倍”，那么的得出“体现在软件定价上”的结论也有些牵强。比如说淘宝（阿里巴巴）的机器的使用率我相信“令人发指地”低，它们浪费机器的现象极其严重。一方面管理人员拼命推广各种时髦的新框架，以图提高机器利用率；另一方面是程序员的问题，其实平均每一个机器上跑不了什么功能，就是仗着机器数量多、分布式，来消掉了问题的“尖峰”。对他们来说，不是不知道大量机器实际浪费着，大公司极力掩饰这种浪费情况，是不得已的做法，因为他们没有能力、感觉没把握、顾不上提高机器利用率。 而你是只看自己的问题的冰山的一角，并且把它当作全部。你没有想到大公司其实机器利用率特别低，你以为互联网公司是以机器利用率为产品定价高低的准绳。这说明你把机器的成本看得很重，就好像僧侣把手中的一个钵看成自己的全部家当，而他没有其他家当了。 我并不是说用或者不用EF，我并不用EF是其它原因（例如我们以 MongoDB为核心）。我说的是，互联网软件软件定价并不是这样产生的，许多重要的应用甚至是免费的。[/quote] 这个是我视野所限，确实不了解这个情况

[爱睡觉的阿狸]

不明觉厉，

[圣殿骑士18]

引用 11 楼 wanghui0380 的回复:

类似楼主的要求，其实正常情况下是混合架构，并非绝对的纯cs，纯bs这种东西 至于你说的多套view其实不必困惑，因为他也是非常正常的方式，因为做为UI一向变化的比纯逻辑快，你只需要承认这点，那么你就自然知道view的修改频率也快，自然存在多套view也十分正常 而ORM这块其实并不在考虑范围以内，ORM从名字你可以看出来他是关系，对象映射，同时是数据持久。那么对于架构者来说，通常这个并不在考虑范围以内，作为架构者我们说用什么都可以用，如果你ORM可以用，你nosql可以用，你MapReduce分布也可以用 而性能考虑其实被博客园粉给夸大了，我们说具体问题具体分析，还是二八原则，系统的8成功能用常规ORM就可以应对，就是个别性能原因也并非就是博客园那种非A就B的选项（谁说ORM我就不能隔离分析，单独优化，单独给SQl滴），至于另外2成的功能你可以另外考虑，比如nosql，比如net4j这种图形数据库，比如MapReduce这类横向分布式文件数据处理 ps：其实从MapReduce这个玩意就可以看出什么性能问题，根本就不是博客园那种非A就B的人能理解的，如果你想博客园那样考虑就根本不会出现MapReduce这种东西，MapReduce使用csv文本做数据提供？？这个性能！！！ MapReduce使用100台机器分布存储，你一句select要从100台机器查询？？这个性能！！！！ 但MapReduce就是出现了，而且很成功！！毕竟网络发展速度比硬盘IO发展速度快的多

啊呀，名词太多了，都不会呀。我的想法是，每个技术点上，掌握一个趁手的技术工具，先做起来，没那么多精力什么都学

[圣殿骑士18]

引用 15 楼 starfd 的回复:

ef支持直接写sql的，对于有性能要求的语句，但自动生成的又达不到自己要求的，可以考虑这种方式

恩，这个是个思路

[showjim]

引用 28 楼 zanfeng 的回复:

连SQL都不想写了。算是干啥呢。。。一群程序员SQL语句都不会优化了，还能指望这个程序员干啥呢。

六年没有在应用程序中写过 SQL 了，如果性能依赖于数据库或者 SQL 语句，那么数据结构与算法不是白学了？

[wanghui0380]

因应该了解一件事情，就是作为设计师，架构师通常是综合考量，而就单单纠结一句sql 你不能总纠结，这任务必须使用“特种作战”，就要把所有部队都转编为特种兵要求。通常系统有自己的设计标准，比如对于以w为标准的我要求10毫秒出结果，150毫秒页面渲染呈现，对于T级数据我要500毫秒出结果，1秒出页面渲染 那么你认为你必须要求所有必须最优有没有意义，其实没有意义。对于非必要的东西，无需考虑！因为我们首先需要保证解决瓶颈，而非每条东西都锱铢必较，你优化一条常规业务的sql让他减少了5毫秒，但是我说没有意义，因为这个页面和逻辑本身在“客户忍受范围内”，你花两小时优化减少了5毫秒这个其实没有意义，但是如果说系统瓶颈级别的优化结果就完全不一样，把3秒的系统瓶颈解决到1秒内这才是正常逻辑

[dzh523]

我觉得离主流技术方向远不远并不是很重要，重要的是各有所长，把一件事情做到最高点。

[圣殿骑士18]

引用 12 楼 sp1234 的回复:

[quote=引用 9 楼 daixf_csdn 的回复:] 硬件我还会考虑用C端，使用WPF或者UWP，或者Windows Service实现。网页和设备C端使用比如websocket实现通讯

你没有看懂回复者的意思。 Hybrid 混合架构是一个趋势，而你还是只考虑传统的模式。[/quote] 好，多谢指点，去了解一下

引用 12 楼 sp1234 的回复:

[quote=引用 9 楼 daixf_csdn 的回复:] 硬件我还会考虑用C端，使用WPF或者UWP，或者Windows Service实现。网页和设备C端使用比如websocket实现通讯

你没有看懂回复者的意思。 Hybrid 混合架构是一个趋势，而你还是只考虑传统的模式。[/quote] 呵，这个我以前看你提过，已经记下了，有空研究

[圣殿骑士18]

引用 22 楼 wanghui0380 的回复:

因应该了解一件事情，就是作为设计师，架构师通常是综合考量，而就单单纠结一句sql 你不能总纠结，这任务必须使用“特种作战”，就要把所有部队都转编为特种兵要求。通常系统有自己的设计标准，比如对于以w为标准的我要求10毫秒出结果，150毫秒页面渲染呈现，对于T级数据我要500毫秒出结果，1秒出页面渲染 那么你认为你必须要求所有必须最优有没有意义，其实没有意义。对于非必要的东西，无需考虑！因为我们首先需要保证解决瓶颈，而非每条东西都锱铢必较，你优化一条常规业务的sql让他减少了5毫秒，但是我说没有意义，因为这个页面和逻辑本身在“客户忍受范围内”，你花两小时优化减少了5毫秒这个其实没有意义，但是如果说系统瓶颈级别的优化结果就完全不一样，把3秒的系统瓶颈解决到1秒内这才是正常逻辑

我是有点完美主义，现在好多了，谢谢提醒

[圣殿骑士18]

引用 30 楼 sbwwkmyd 的回复:

引用 28 楼 zanfeng 的回复:

连SQL都不想写了。算是干啥呢。。。一群程序员SQL语句都不会优化了，还能指望这个程序员干啥呢。

六年没有在应用程序中写过 SQL 了，如果性能依赖于数据库或者 SQL 语句，那么数据结构与算法不是白学了？

大家工作方向不同吧，写算法的很少用数据库，做应用系统则必须要数据库

[showjim]

引用 32 楼 daixf_csdn 的回复:

大家工作方向不同吧，写算法的很少用数据库，做应用系统则必须要数据库

做 WEB 开发而已，只是一些简单常用的算法与数据结构用于数据缓存处理，和专业做算法的不是一个等级的。

[五更琉璃]

楼主遇到的 2个问题 和你 目前采用的架构没什么 关系。

[baidu_27549073]

引用 1 楼 microtry 的回复:

楼主所提到的问题更多的还是生产能力和设计能力的问题 1.不管客户端是什么平台，只要是存在多种UI实现的需求， 如果想大幅度的重用或者说提升开发效率，MVC设计模式是首选方案， 业务逻辑模型（M）是所有平台通用，控制器模型（C）和视图模型（V）是平台内通用； 2.虽然我是不使用ORM的，但是我并不认为EF有什么性能问题， 问题在于，我见过很多ORM开发者或者使用者，都非常不重视数据库开发， 数据访问的性能，和开发效率的问题，最终需要数据库开发来解决 ORM背后所体现的ER设计方法或者说建模方法，应用于数据服务的开发，或者数据库开发，是比较合适的， 而应用于复杂的应用程序开发是不合适的

原来是这样，以前用的ado.net,感觉很自己很牛逼，再复杂的业务也能写出来。但是后来用了ef.碰到稍微复杂一点的左连接，右连接，case when,查出来后在添加两列其他的数据再转json之类的真是太烦了，感觉还不如直接写sql

[cxsir]

新手表示观望学习

[圣殿骑士18]

引用 39 楼 hanjun0612 的回复:

轻量级的orm可以尝试使用 dapper。 或者在原有的ef框架上考虑仓储模式和单元模式，并且ef是支持sql的。db.Database.SqlQuery<Model>(sql, parameters)。 当然，如果楼主想要少维护一些view，那么可以考虑使用hbulider来开发app和ipad端的网页。这样至少adnroid和ios的view端可以减少开发成本。 然后通过webapi调用来填充app和ipad数据。 楼主说的ef生成sql的嵌套问题的确由来已久。目前我也就直接通过db.Database.SqlQuery<Model>(sql, parameters)直接写sql语句来回避这个问题。

hbulider没用过，记下了

[正怒月神]

轻量级的orm可以尝试使用 dapper。 或者在原有的ef框架上考虑仓储模式和单元模式，并且ef是支持sql的。db.Database.SqlQuery<Model>(sql, parameters)。 当然，如果楼主想要少维护一些view，那么可以考虑使用hbulider来开发app和ipad端的网页。这样至少adnroid和ios的view端可以减少开发成本。 然后通过webapi调用来填充app和ipad数据。 楼主说的ef生成sql的嵌套问题的确由来已久。目前我也就直接通过db.Database.SqlQuery<Model>(sql, parameters)直接写sql语句来回避这个问题。

[正怒月神]

趁着还没结贴，我来蹭点分。哈哈哈

[圣殿骑士18]

引用 45 楼 lovelj2012 的回复:

我对写代码，兴趣越来越淡~

同感，我现在写代码，越来越不想写长篇的复杂的代码。追求写的越少越好，如果一行可以写就的代码，非要拆成5行写，我看到这种代码会抓狂。 我追求代码书写上的最高境界是：每一句代码，即可解释一个业务逻辑点。 那么写代码就变成了：不是在“写代码”，而是在整理我的业务逻辑思路。这我还是有兴趣的

[fei80230901]

感觉像精和通的问题

[江南小鱼]

我对写代码，兴趣越来越淡~