各位CSDN朋友们，请对这个问题拍砖。
下面我先开个头：
? 节省人力成本。
? 缩短开发周期和发布时间。
? 在不增加开发团队人力和时间的基础上增加了更丰富的常用功能。
? 让开发人员更专注于业务需求，提升核心竞争力。
? 提升系统稳定性和性能。控件经过了长期的优化和严格测试，并且通过了各个不同行业和不同使用者的检验。
话说今晚《变形金刚4》就要上映了。。。。
------解决方案--------------------
还有一点，不仅仅是使用控件（最好是同一系列的，以保持风格一致），还可以使用成熟的组件，以AOP的形式接入系统，最大化的做到构件可重用。
帮你推荐一下，希望大家积极参与。
------解决方案--------------------
从开发人员角度来讲，一定程度上也降低了学习成本，不用再为了一些常见的特定的效果而重载控件了。
------解决方案--------------------
对于公司来说，也降低了由于技术人员流失而给公司带来的技术上的风险，毕竟有个成熟的组件一般都会有成熟的技术支持和技术文档，对于中小型企业来讲更为妥当。
------解决方案--------------------
我觉得这是废话。
在很早很早以前，大师们就提出了一系列的程序设计原则：
”自顶向下，逐步细化“
”模块化设计“
......
”模块化设计“这一条，就涵盖了控件的使用这一手段。
------解决方案--------------------
我能坐等收分不？
------解决方案--------------------
来学习，长见识
------解决方案--------------------
模块化设计，赞同，，，，不过有时候能自己造车轮子最好
------解决方案--------------------
差不多就这些，模块化不仅是为了复用，以复用为目的能促进设计的模块化。
------解决方案--------------------
个人认为，无非就是一个职责的分工而已，你负责写 DB 的设计，他负责界面的设计，我负责功能控件，经理负责吹牛B。等等。
------解决方案--------------------
接分
------解决方案--------------------
可以使用成熟的组建 如 jquery UI Bootstrap 之类的
在B/S已经不使用服务器控件好几年。。
------解决方案--------------------
在使用控件的情况下 也要保证控件的二次开发的能力 最好有源代码 确保控件的漏洞降到最低。
在安全方面来说 共有控件如果有漏洞的话 同样的调用控件会给黑客 病毒的传播制造空间。 造成病毒传播栖息地。
------解决方案--------------------
java菜鸟，路过学习下，欢迎大神们分享自己的心得！
------解决方案--------------------
我觉得主要是节约开发成本,差少开发周发,同样一个功能,自己开发要发几个月甚至更长时间一个控件,可能几天就解决了.而且,更专业,所以使用控件是很好的做法.
------解决方案--------------------
控件式开发，以前做电信监控系统的时候发现的一最大的好处：数据源错得一塌糊涂可是界面上依然显示得相当pro，糊里糊涂就过了检查~------解决方案--------------------
在上一集的变形金刚中，。。。。。。打个酱油，坐等高清版
------解决方案--------------------
使用控件对企业的开发人员有好处么？省力了，也失去竞争力了。
------解决方案--------------------
其实我无法按照你说的这个角度来补充。你列出的角度，更加适合的是针对那些业余的开发人员的，那些认为“越是低级的写法越是体现技术水平”的人的回应。你的出发点是“用控件开发商的控件”这个角度。
我不愿参与你说的这个角度（这个层面）的讨论，除非对方自己也开发控件。
一个专业的开发团队，那么控件开发技术体现的是一种架构策略。一个产品中总应该有几十个通用的控件，有80%以上的代码都是自定义的UI控件，然后只有不足10%的代码属于“胶水”性质的、易失去的（随时准备根据用户需求而重新改变的）代码。
这里说的就不是什么“自顶向下开发”，也不是什么“自底向上开发”。一个团队有自己的一整套通用的UI组件，主要精力用于研发自己的组件。然后拿出10%~20%的精力来引导用户、满足用户的特殊UI定制需求。
有些小作坊的做法是，自己没有控件开发意识，没有想去“正对一个行业整体需求进行平台设计”的意识，只会用点别人的控件，只会根据所谓的“需求分析”去进行界面的“增删改查功能分解”，然后分给几个人分头去“开发”，而这几个人则是使用比较低级简单的控件，甚至是连控件都不会而是在哪里各自为战地胡乱反复粘贴和凌乱修改许多遍网上的代码（这样的人还觉得自己的水平比用控件的人水平高）。对于这种小作坊，他看人家比较专业的团队进行软件开发的过程就会怎么多不理解，就会以为人家是“在那里搞研究呢”而不如自己的小作坊的做法更高效率。而这种小作坊还很多。
我们讨论控件，找对那些真正有高效率的团队，那些自己研发通用组件并且反复用于自己的各项目产品中的团队。而如果遇到了一个纯粹小作坊的程序员，其实你无需跟他过多讲控件的思路，讲了也就是被他偶尔才用一下。
------解决方案--------------------
什么叫“使用控件”？什么叫“控件”？如果说，控件代表一些已经预先开发好的代码库（主要指界面），那么使用控件本身是很自然的事情，开发者做的事情就是编写代码给自己用，给别人用，以及用别人的代码。商业控件无非就是这种协作过程的商业合作形式，值得拿出来讨论么。
------解决方案--------------------
就你说的这些“好处”其实就是商品交换的好处。用自己擅长的劳动成果换取不擅长的，8000年前的古人都明白的道理。
------解决方案--------------------
我比较喜欢造轮子，可是造了一些东西之后我果断弃之了，因为我知道“只要明白这其中的原理，推而广之便可举一而反三”。
要清楚自己是应用型还是研发型，最后支持一下楼主造的轮子。
------解决方案--------------------
我也觉得似乎要做广告。
在这一点上很赞同26楼的观点。
------解决方案--------------------
除非你的控件提供的功能很强大，方方面面都考虑到了，然后又能提供源代码自己可以改造。
这样才在实际应用的时候才有用。不然也就是个样子货而已。
用户各种奇葩的需求都会有，实际开发过程中，总不能都跟用户说，你要的功能控件达不到，我们完成不了。
------解决方案--------------------
控件的普及的话，在我的实践经验来看，如果接口定义的明确的话可以极大地简化开发过程，并保证模块的稳定性，在使用控件的时候可以避免出现测试过程需要软件全盘测试的问题。
不过凡事总是两面的，如果接口定义的不好，接口层次给的不明确，使用上会受到很到的限制。
个人认为接口定义可以分为两个层面走，一个是底层功能层面，有什么功能给什么接口，另一个是应用层面，可以按照一些比较常见的使用场景封装一些应用实例接口，可以一步调用到位。
------解决方案--------------------
嘻嘻，过来人啊。
控件的使用在系统级基础上确实不占据太多分量(相对业务逻辑)，如在银行、电信的系统中，UI土鳖的要死，拖拖拉拉摆放几个控件上去，传递DataSet显示、渲染控件。
不过在Web下，情况有些变化，更多的牛逼程序员想的是要DIY、开源，毕竟在Web下，用户的黏性不高，UI做的好不好，决定了用户的页面停留时间，更不用说业务合理性了。
我的建议是：企业精力许可，可自行DIY控件，尤其是程序员热情高涨，又没有多少工作要做的时候，做控件绝对是非常有挑战的工作--架构、UI、接口、缓存等等。
小作坊，能盗版还是盗版吧，省钱比啥都强，在我们这个国度，先不要考虑创新，活下来是最重要的，
大企业，财大气粗的，用点正版的，最新版本的，确实能节约人力成本--不是一心半点（基于大企业拿到大项目的概率高的多基础）。
欢迎大家拍砖。