C#---当前应用领域最广的高级编程语言

c_sharp_fans 2011-03-02 08:58:34
(个人拙见,欢迎讨论,但请对应本文主旨,谢绝语言攻击)

在当前的主流开发语言中,c/c++一般用在底层和桌面程序;java开发的桌面应用和RIA应用可以说少之又少;php,python等一般只是用在web开发上;而只有C#,它可以用来开发桌面应用程序、Web应用程序、RIA应用程序(Silverlight),和智能手机应用程序(当然,将来肯定也会包括windows平板电脑应用)。可以说是当前应用领域最广,最全面的高级开发语言。

--

1.桌面应用程序

这个就不用多说了,当前Win桌面应用程序的首选。在WinXP以前,由于需要单独安装.NET Framework,用C#开发的桌面应用程序比较少。现在,随着Win7的普及(Win7自带.NET Framework3.0),C#桌面应用一定会越来越多。

典型应用:fetion(飞信)。

2.Web应用

这个可能被认为是弱项。因为php,java等占有率高。但毫无疑问,没有人能忽视C#在该领域的地位。除了微软自己旗下的大型网站(msn,hotmail等),是用的C#,其他的国内外应用也是多不胜数。

典型应用如:国外的myspace,dell,newegg,国内的360buy,dangdang,vancl,sdo,ctrip,58,dianping等等。企业级的如:招商网银等。

3.RIA应用程序

这方面的对手只有Adobe的flash了,作为后起之秀,Silverlight短短几年已经升级到4.0版本,相关应用也越来越多。有人说html5时代到了,不需要它。可html5说到底也只是html标签,功能毕竟有限,高级功能肯定需要插件来扩展。就像现在的html需要js来增强功能,将来的html5时代也离不开silverlight,flash。

典型应用如:pptv(http://cool.pptv.com/),江苏卫视(http://live.jstv.com/),新浪财经(http://vip.stock.finance.sina.com.cn/silverpulse/),中国人寿(http://pacs.clpc.com.cn/PACS/)等等。

4.智能手机应用

这方面可以说是唯一的短板了,因为windows phone/mobile的占有率太小。但随着诺基亚和微软的结盟,wp7的前景相信无人能够小觑。

--

总结

当然,你可能会说,它啥都能做,但啥都不行。可是,相信上面举的那些典型应用,没人能够无视吧?确实,fetion不如qq,360buy不如taobao,myspace不如facebook等等,但这差距肯定不是技术之罪。并且,它既然能够用来开发fetion,360buy,myspace等应用,难道还不够成功么?

原帖:http://blog.csdn.net/c_sharp_fans/archive/2011/03/02/6217062.aspx



-
...全文
2212 51 打赏 收藏 转发到动态 举报
写回复
用AI写文章
51 条回复
切换为时间正序
请发表友善的回复…
发表回复
  • 打赏
  • 举报
回复
都别争了,看C#语言的在今年的编程语言排行榜上就知道势头如何了。前三位是java,C,C#,C#处于强劲上升势头,C微弱上升势头,java处于轻微下降势头。C#比java晚了很多年,所以这个追赶的过程一定会有的,java的命运不好说,oracle最近和sun传出不和谐声音,单从这点就可以看出这个团队很让人担忧,IBM也对Sun公司的硬件业务下狠手,这样oracle对sun公司的态度会很不好。
ajiangfeijun 2011-09-17
  • 打赏
  • 举报
回复
同意楼主
放下丶追寻 2011-09-17
  • 打赏
  • 举报
回复
现在是安卓免费的系统,谁都喜欢免费的,说以java还是很好的
星小野 2011-09-17
  • 打赏
  • 举报
回复
c_sharp_fans 2011-03-03
  • 打赏
  • 举报
回复
[Quote=引用 30 楼 nocky 的回复:]
说到应用领域C#跟C都差太多了
1. 操作系统 C#做不了
2. 嵌入式,特别是对于裸机C#做不了
3. 高性能计算C#做不了
其它领域C#能做的C都可以做,何言C#应用领域最广?
[/Quote]

我说的是目前的实际应用情况。
C确实什么都能做,但目前除了底层和桌面应用,其他地方用C的很少吧?
尤其是在WEB,RIA上,有多少用C的。
hdt_mj 2011-03-03
  • 打赏
  • 举报
回复
[Quote=引用 39 楼 hdt 的回复:]
汽车应用广了,司机却失业了
[/Quote]1
zjx198934 2011-03-03
  • 打赏
  • 举报
回复
c#是为.net量身打造的! 它为什么会火 还得到大家的广泛应用 是因为它的靠山是微软 有了微软无尽的技术支持和更新扩展 才让它有现在的成就 如果哪天微软跨了 ...
vrhero 2011-03-03
  • 打赏
  • 举报
回复
扯了半天跟C#没啥关系...标题党...
秋的红果实 2011-03-03
  • 打赏
  • 举报
回复
从计算机系统结构讲,计算机被分为好多虚拟机层,每一层上都有相应的语言,机器级语言、操作系统级语言、汇编语言、高级语言(大致这样),越往后越容易使用,好多功能的实现都被“集成”了,这样开发人员省力了,但是,这样做缺少了灵活性,也容易懒惰,一个软件系统各模块之间的逻辑关系 与 一个只有百十来条代码的模块内部个函数之间的关系,往往很相似。C#属于最高级的语言,我认为不能广泛应用,我学习C#是因为web程序不是用C++,不得已而为之
cjnkd 2011-03-03
  • 打赏
  • 举报
回复
上手容易,深入难!
真相重于对错 2011-03-03
  • 打赏
  • 举报
回复
汽车应用广了,司机却失业了
zzmsyt 2011-03-03
  • 打赏
  • 举报
回复
我是从c#起手的,之后才学的c/c++,每个语言都有其优点,只是个人爱好不同罢了,这又不是武林大会,谁武功高谁当盟主。说白了,学什么语言,最主要的是看Boss!
瑾安 2011-03-03
  • 打赏
  • 举报
回复
不能忽视其他语言啊
linchb_ 2011-03-03
  • 打赏
  • 举报
回复
现在的飞信不用.NET开发了
咸清 2011-03-03
  • 打赏
  • 举报
回复
我是说稍微高级一点的驱动,不是底层驱动
咸清 2011-03-03
  • 打赏
  • 举报
回复
C#做驱动很累,几乎不现实,不如C。
hztltgg 2011-03-03
  • 打赏
  • 举报
回复
[Quote=引用 28 楼 c_sharp_fans 的回复:]
引用 27 楼 hztltgg 的回复:
所以我也是说,c#应用广是个表面现象,.net才是关键,你题目拼命吹捧c#,具体又是说.net,让我这种用vb.net的人看了多难受呀!

哦。原来如此。呵呵。
那不好意思了。别难受,怎么说咱也都是.net平台的。
不过,C#确实也比VB.NET多一项优势,就是目前开发Windows Phone程序只能用C#。呵呵。
[/Quote]

VB.NET是支持Windows Phone开发的,倒是xna现在还不支持,不过也可以变通,先建c#,然后转到vb.net里
hztltgg 2011-03-02
  • 打赏
  • 举报
回复
[Quote=引用 12 楼 c_sharp_fans 的回复:]
引用 3 楼 hztltgg 的回复:

你说的是平台,是.net平台,而不是语言,vb.net也同样可以实现你说的这些功能。

语言侧重于一种算法,是表达思维的一种方式,平台才是应用的基础,桌面,web,手机,都是针对平台而言,语言再高级,用无数个委托而没有手机的api,也一样不能在手机上发一条短信


确实如此。
但选择了语言,其实就是选择了平台。
.net虽然说是跨语言,v……
[/Quote]

错了,选择了语言,绝不就是选择了平台,事实上,你说的选择了c#,但你选择了平台么?你打算桌面,网站,RIA,手机全面开花,均有建树么?你有这么多精力么?

事实上,人们都是先选择了平台,后选择的语言,计算机专业的同学都知道,最后都要确定方向,网络的,程序的,嵌入式的,并深入学习相关的领域。而语言从来都只是作为一个工具使用,并且可以随时替换。
yalan 2011-03-02
  • 打赏
  • 举报
回复
只要C#跨平台了,CSharper就可以做人挺好了
c_sharp_fans 2011-03-02
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 hztltgg 的回复:]

你说的是平台,是.net平台,而不是语言,vb.net也同样可以实现你说的这些功能。

语言侧重于一种算法,是表达思维的一种方式,平台才是应用的基础,桌面,web,手机,都是针对平台而言,语言再高级,用无数个委托而没有手机的api,也一样不能在手机上发一条短信
[/Quote]

确实如此。
但选择了语言,其实就是选择了平台。
.net虽然说是跨语言,vb.net,python都可以用,但实际上大部分人还是用c#。
而java就更不用说了,选择java,就是选择了jee,j2ee,j2se等平台。
加载更多回复(24)
第一部分 背景知识 第1章 应重视的价值,也是对过去几年的沉重反思 1.1 总体价值 1.2 应重视的架构风格 1.2.1 焦点之一:模型 1.2.2 焦点之二:用例 1.2.3 如果重视模型,就可以使用领域模型模式 1.2.4 慎重处理数据库 1.2.5 领域模型与关系数据库之间的阻抗失配 1.2.6 谨慎处理分布式 1.2.7 消息传递很重要 1.3 对过程的各个组成部分的评价 1.3.1 预先架构设计 1.3.2 领域驱动设计 1.3.3 测试驱动开发 1.3.4 重构 1.3.5 选择一种还是选择组合 1.4 持续集成 1.4.1 解决方案(或至少是正确方向上的一大步) 1.4.2 从我的组织汲取的教训 1.4.3 更多信息 1.5 不要忘记运行机制 1.5.1 有关何时需要运行机制的一个例子 1.5.2 运行机制的一些例子 1.5.3 它不仅仅是我们的过错 1.6 小结 第2章 模式起步 2.1 模式概述 2.1.1 为什么要学习模式 2.1.2 在模式方面要注意哪些事情 2.2 设计模式 2.3 架构模式 2.3.1 示例:层 2.3.2 另一个示例:领域模型模式 2.4 针对具体应用程序类型的设计模式 2.5 领域模式 2.6 小结 第3章 TDD与重构 3.1 TDD 3.1.1 TDD流程 3.1.2 演示 3.1.3 设计效果 3.1.4 问题 3.1.5 下一个阶段 3.2 模拟和桩 3.2.1 典型单元测试 3.2.2 声明独立性 3.2.3 处理困难因素 3.2.4 用测试桩替换协作对象 3.2.5 用模拟对象替换协作对象 3.2.6 设计含义 3.2.7 结论 3.2.8 更多信息 3.3 重构 3.4 小结 第二部分 应用DDD 第4章 新的默认架构 4.1 新的默认架构的基础知识 4.1.1 从以数据库为中心过渡到以领域模型为中心 4.1.2 进一步关注DDD 4.1.3 根据DDD进行分层 4.2 轮廓 4.2.1 领域模型示例的问题/特性 4.2.2 逐个处理特性 4.2.3 到目前为止的领域模型 4.3 初次尝试将UI与领域模型挂接 4.3.1 基本目标 4.3.2 简单UI的当前焦点 4.3.3 为客户列出订单 4.3.4 添加订单 4.3.5 刚才我们看到了什么 4.4 另一个维度 4.4.1 领域模型的位置 4.4.2 孤立或共享的实例 4.4.3 有状态或无状态领域模型实例化 4.4.4 领域模型的完整实例化或子集实例化 4.5 小结 第5章 领域驱动设计进阶 5.1 通过简单的TDD实验来精化领域模型 5.1.1 从Order和OrderFactory的创建开始 5.1.2 一些领域逻辑 5.1.3 第二个任务:OrderRepository+OrderNumber 5.1.4 重建持久化的实体:如何从外部设置值 5.1.5 获取订单列表 5.1.6 该到讨论实体的时候了 5.1.7 再次回到流程上来 5.1.8 总览图 5.1.9 建立OrderRepository的伪实现 5.1.10 简单讨论一下保存 5.1.11 每个订单的总量 5.1.12 历史客户信息 5.1.13 实例的生命周期 5.1.14 订单类型 5.1.15 订单的介绍人 5.2 连贯接口 5.3 小结 第6章 准备基础架构 6.1 将POCO作为工作方式 6.1.1 实体和值对象的PI 6.1.2 是否使用PI 6.1.3 运行时与编译时PI 6.1.4 PI实体/值对象的代价 6.1.5 将PI用于存储库 6.1.6 单组存储库的代价 6.2 对保存场景的处理 6.3 建立伪版本机制 6.3.1 伪版本机制的更多特性 6.3.2 伪版本的实现 6.3.3 影响单元测试 6.4 数据库测试 6.4.1 在每次测试之前重置数据库 6.4.2 在测试运行期间保持数据库的状态 6.4.3 测试之前重置测试所使用的数据 6.4.4 不要忘记不断演变的模式 6.4.5 分离单元测试和数据库调用测试 6.5 查询 6.5.1 单组查询对象 6.5.2 单组查询对象的代价 6.5.3 将查询定位到哪里 6.5.4 再次将聚合作为工具 6.5.5 将规格用于查询 6.5.6 其他查询选择 6.6 小结 第7章 应用规则 7.1 规则的分类 7.2 规则的原则及用法 7.2.1 双向规则检查:可选的(可能的)主动检查,必需的(和自动的)被动检查 7.2.2 所有状态(即使是错误状态)都应该是可保存的 7.2.3 规则应该高效使用 7.2.4 规则应该是可配置的,以便添加自定义规则 7.2.5 规则应与状态放在一起 7.2.6 规则应该具有很高的可测试性 7.2.7 系统应阻止我们进入错的状态 7.3 开始创建API 7.3.1 上下文,上下文,还是上下文 7.3.2 数据库约束 7.3.3 将规则绑定到与领域有关的转换,还是绑定到与基础架构有关的转换 7.3.4 精化原则:所有状态,即使是错误状态,都应该是可保存的 7.4 与持久化有关的基本的规则API的需求 7.4.1 回到已发现的API问题上 7.4.2 问题是什么 7.4.3 我们允许了不正确的转换 7.4.4 如果忘记检查怎么办 7.5 关注与领域有关的规则 7.5.1 需要合作的规则 7.5.2 使用基于集合的处理方法 7.5.3 基于服务的验证 7.5.4 在不应该转换时尝试转换 7.5.5 业务ID 7.5.6 避免问题 7.5.7 再次将聚合作为工具 7.6 扩展API 7.6.1 查询用于设置UI的规则 7.6.2 使注入规则成为可能 7.7 对实现进行精化 7.7.1 一个初步实现 7.7.2 创建规则类,离开最不成熟的阶段 7.7.3 设置规则列表 7.7.4 使用规则列表 7.7.5 处理子列表 7.7.6 一个API改进 7.7.7 自定义 7.7.8 为使用者提供元数据 7.7.9 是否适合用模式来解决此问题 7.7.10 复杂规则又是什么情况 7.8 绑定到持久化抽象 7.8.1 使验证接口成为可插入的 7.8.2 在保存方面实现被动验证的替代解决方案 7.8.3 重用映射元数据 7.9 使用泛型和匿名方法 7.10 其他人都做了什么 7.11 小结 第三部分 应用PoEAA 第8章 用于持久化的基础架构 8.1 持久化基础架构的需求 8.2 将数据存储到哪里 8.2.1 RAM 8.2.2 文件系统 8.2.3 对象数据库 8.2.4 关系数据库 8.2.5 使用一个还是多个资源管理器 8.2.6 其他因素 8.2.7 选择和前进 8.3 方法 8.3.1 自定义手工编码 8.3.2 自定义代码的代码生成 8.3.3 元数据映射(对象关系(O/R)映射工具) 8.3.4 再次选择 8.4 分类 8.4.1 领域模型风格 8.4.2 映射工具风格 8.4.3 起点 8.4.4 API焦点 8.4.5 查询风格 8.4.6 高级数据库支持 8.4.7 其他功能 8.5 另一个分类:基础架构模式 8.5.1 元数据映射:元数据的类型 8.5.2 标识字段 8.5.3 外键映射 8.5.4 嵌入值 8.5.5 继承解决方案 8.5.6 标识映射 8.5.7 操作单元 8.5.8 延迟加载/立即加载 8.5.9 并发控制 8.6 小结 第9章 应用NHibernate 9.1 为什么使用NHibernate 9.2 NHibernate简介 9.2.1 准备 9.2.2 一些映射元数据 9.2.3 一个小的API示例 9.2.4 事务 9.3 持久化基础架构的需求 9.3.1 高级持久化透明 9.3.2 持久化实体的生命周期所需的特定特性 9.3.3 谨慎处理关系数据库 9.4 分类 9.4.1 领域模型风格 9.4.2 映射工具风格 9.4.3 起点 9.4.4 API焦点 9.4.5 查询语言风格 9.4.6 高级数据库支持 9.4.7 其他功能 9.5 另一种分类:基础架构模式 9.5.1 元数据映射:元数据类型 9.5.2 标识字段 9.5.3 外键映射 9.5.4 嵌入值 9.5.5 继承解决方案 9.5.6 标识映射 9.5.7 操作单元 9.5.8 延迟加载/立即加载 9.5.9 并发性控制 9.5.10 额外功能:验证挂钩 9.6 NHibernate和DDD 9.6.1 程序集概览 9.6.2 ISession和存储库 9.6.3 ISession、存储库和事务 9.6.4 得到了什么结果 9.7 小结 第四部分 下一步骤 第10章 博采其他设计技术 10.1 上下文为王 10.1.1 层和分区 10.1.2 分区的原因 10.1.3 限界上下文 10.1.4 限界上下文与分区有何关联 10.1.5 向上扩展DDD项目 10.1.6 为什么对领域模型——SO分区 10.2 SOA简介 10.2.1 什么是SOA 10.2.2 为什么需要SOA 10.2.3 SOA有什么不同 10.2.4 什么是服务 10.2.5 服务中包括什么 10.2.6 深入分析4条原则 10.2.7 再来看一下什么是服务 10.2.8 OO在SOA中的定位 10.2.9 客户-服务器和SOA 10.2.10 单向异步消息传递 10.2.11 SOA如何提高可伸缩性 10.2.12 SOA服务的设计 10.2.13 服务之间如何交互 10.2.14 SOA和不可用的服务 10.2.15 复杂的消息传递处理 10.2.16 服务的可伸缩性 10.2.17 小结 10.3 控制反转和依赖注入 10.3.1 任何对象都不是孤岛 10.3.2 工厂、注册类和服务定位器 10.3.3 构造方法依赖注入 10.3.4 setter依赖注入 10.3.5 控制反转 10.3.6 使用了Spring.NET框架的依赖注入 10.3.7 利用PicoContainer.NET进行自动装配 10.3.8 嵌套容器 10.3.9 服务定位器与依赖注入的比较 10.3.10 小结 10.4 面向方面编程 10.4.1 热门话题有哪些 10.4.2 AOP术语定义 10.4.3 .NET中的AOP 10.4.4 小结 10.5 小结 第11章 关注UI 11.1 提前结语 11.2 模型-视图-控制器模式 11.2.1 示例:Joe的Shoe Shop程序 11.2.2 通过适配器简化视图界面 11.2.3 将控制器从视图解耦 11.2.4 将视图和控制器结合起来 11.2.5 是否值得使用MVC 11.3 测试驱动的Web窗体 11.3.1 背景 11.3.2 一个示例 11.3.3 领域模型 11.3.4 GUI的TDD 11.3.5 Web窗体实现 11.3.6 小结 11.3.7 用NMock创建模拟 11.4 映射和包装 11.4.1 映射和包装 11.4.2 用表示模型来包装领域模型 11.4.3 将表示模型映射到领域模型 11.4.4 管理关系 11.4.5 状态问题 11.4.6 最后的想法 11.5 小结 11.6 结束语 第五部分 附录 附录A 其他领域模型风格 附录B 已讨论的模式的目录

110,538

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧