模块化Java：声明式模块化
本文是模块化Java系列文章的第4篇，介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起，而无需让代码依赖于OSGI API。
新闻
Spring.NET在.NET新时代的尴尬
作者 王翔 发布于 2008年2月19日 上午5时41分
业界普遍接受的观点是：开发思想是重要的，相对而言用什么平台实现是次要的。从这个意义上看Spring.NET（或者说Spring）在构思框架的核心价值的时，着重面向的领域是“依赖注入”和AOP两个方面，但“分布式调用”以及“基于整个调用栈后动态对象生成”这两个概念对于Spring而言只是方面（Aspect）而已，但对于开发人员而言他俩确实是天天都要面对的问题。
Spring.NET继承Java版Spring的衣钵，在一些.NET项目中已经被采用，并且已经被部分企业用作其开发框架的标准组成部分，但对于更大规模或者更小规模的.NET项目而言他处处给人以高不成、低不就的尴尬感觉：
- 向上，他不像WCF可以获得微软服务器产品家族的支持，更远远逊色于类似COM+的待遇，但规模比较大的.NET项目又往往需要集成BizTalk、ISA、SMS、Exchange、SQL Server等一系列产品。如果使用Spring.NET（或者加上NHibernate）也就意味着虽然运行着较高版本的服务器产品只能屈就于有限功能集的使用。另外，在Spring.NET的设计中似乎对于运维能力以及性能指标的采集总是基于日志系统的，但如果什么内容都写到日志，这本身就是很大的性能损失；尤其在以WMI为标准的.NET企业环境中，Spring.NET在运维能力设计上存在不小的缺陷；
- 向下，Spring.NET 1.1在试图弥合其与ASP.NET的差异，不过似乎又慢了一步，因为ASP.NET自己的框架也在随着.NET 3.5的发布发生变化。与此同时，ADO.NET的异步处理能力、LINQ的动态对象映射能力处处都直指Spring.NET的最佳排档——NHibernate，如果准备启用新.NET 3.5开发的团队那么就需要做一个选择，继续跟着3rd开源的衣钵还是跟着.NET自己的技术走。
在EntLib 4发布前夕，P&P团队已经在codeplex上公布了相关Unity的计划及其CTP版本，其他的Application Block也陆续迁移到Unity之上。虽然EntLib只是整个.NET开源的沧海一粟，但其风向标意义明显，其企业级特性支持可以直接用于.NET Native的WCF，而对对象的管理则全部交给Unity完成，这个组合不仅可以向上贯通微软一系列服务器产品，也可以与Office System、WMI集成在一起。并且随着微软相关技术平台的升级，WCF和Unity也会逐步更新，而且会与微软的服务器产品、Office System产品、开发工具以及监控产品结合在一起。对于.NET团队，尤其是实施较大规模.NET项目（包括产品集成）的团队而言，这是一个新的选择。
思想挺好
发表人
Randy Chen
发表于
2008年2月19日 下午7时28分
我来说两句
发表人
春鹏 张
发表于
2008年2月19日 下午7时28分
Re: 我来说两句
发表人
hello hello
发表于
2008年2月20日 上午12时22分
Re: 我来说两句
发表人
春鹏 张
发表于
2008年2月21日 下午7时26分
Re: 我来说两句
发表人
hello hello
发表于
2008年2月22日 下午5时37分
根据项目的情况吧。
发表人
远 刘
发表于
2008年5月8日 上午2时47分
-
spring.net更多能带来的只是参考和学习其思想
-
看你是领域对象驱动还是数据库驱动了。LINQ，目前只支持SqlServer，地位有点尴尬。
-
LINQ不仅仅是SQL Server， 已经有10多个组织提供了14个主要数据库产品的驱动了。
事情明摆着：微软自己做SqlServer版就行了，其他的厂商你要不怕丢掉Windows用户市场，你就等着好了。
兴许两年后给你提供一个类似当年odbc的驱动，至于支持的力度，是不是拿着Oracle 13g要当8i用，这个就没关系了。 -
两年，公司可等不起啊。
-
是啊。其实更等不起的是我们自己。 :)
技术托拉斯的时代。 -
这个问题，我觉得也要根据项目的情况吧。
项目自身也存在生命周期，量体裁衣吧。
个人真的不看好第三方的东西，包括castle这个级别的框架，优秀的思想，微软都会吸收进来并且融合在自身强大的背景支持当中，在这点上，第三方框架显得弱不经风啊。
6 条回复
关注此讨论 回复