我也正为此事苦恼之中
对别人说上一句"这个问题要看你的项目而定"
尔在自己定的时候就很难, 特别是我对2都还算喜欢
了解的水平也都还差不多的时候.
.. .. 无解之中

有意思

我冒昧转摘了此文，http://www.sawin.cn/doc/SD/Architect/blueski411.htm。
多谢！

难以整合或整合不了的才重写

路过。
我是这样考虑的，希望有所帮助：
１．先别谈用JAVA还是C#。
２．楼主要先确定系统的当前目标（系统的市场优势和适用范围）和以后目标。
３．在这些目标下系统的架构如何，如何演化。
４．系统总有若干个关键的技术问题，无论用什么框架都需要论证可行性。
５．用JAVA和C#，只要主体上合适就行了。主要看技术支持力度。

另：不知道系统规模如何，６个月是否够？可否考虑稳妥的方法：先把目前各个部分的核心模块封装成组件。在新架构下进行整合。以后再重写呢？

@errorter
我们还有C/S应用的部分，也用Ruby，未知的陷阱太多了

@idior
把评价因素改了，长远的技术选择要兼顾，更重要的眼前，呵呵
对于我们的项目而言，有两个因素：
1.找到一个半成品（开源框架），解决企业应用中的一些共性问题，加快进度
2.解决B/S与C/S下的图形绘制问题，目前Java和Dotnet下都在做这方面的工作。且图形的交互能力，比如拖动图片上的元素，暂不考虑

当然到最后发现，真正决定因素：
1.领导/开发团队喜欢什么
2.开发团队熟悉什么
3.哪种技术能让开发团队先熟悉起来

我们可以仔细想一想，其实我们更多的人还是生活在少数几个人的影子里。我们都知道这样的话，人民是历史的创造者，可真正描述起历史来还不是说某某人的时代，某某人的朝代。这也说明，微软式的专断，是自然的事情。java和dotnet的分别正是民主和集中的体现，你能说哪一种是优良的吗。

@weide

看了你的网站。感觉你们发布了很多应用程序，这样看来似乎SOA比较适合，你们以后可以向ASP（Application Service Provider）发展。

到场的Java开发者，缺少架构师级的能力.

难道就因为这个你们放弃java?!
何况那个了解.net架构师还不是你们公司的。

.net下所有的分布式技术都是分散的。
remoting, es, msmq, ws都是各干各的，完全没有一个统一的模型，至少要等indigo出来才会有所好转。

@weide

The 4 rules help you to identify a system's scale. Normaly a very large scale system can be called Enterprise Level. Many Enterprise Level systems consist of more than one organization and probably span a large physical area.

PS: robber boat is my words.

@非鱼

好半天才凿摸过劲儿来，"robber's boat"，强盗的船，原来就是俗语的“上了贼船”啊，贴切

英语也有这种说法？

◎非鱼

Enterprise Level的界定就是你上次描述的四条？
『
1. Is it a information collecting/organizing/OLAP system?
2. Are you preparing to use Workflow in the coming system?
3. Do you have any complex business process?
4. Is it a real distributed system?
』
或者说Java比之Dotnet在Enterpise Level方面到底强在哪里？

@weide

If the application is not to be an Enterprise Level one, .net would not be a bad choice. Even so I want to state that .net is a "robber's boat" besides technology aspect. ^_^

今天化了一天的时间开评论会；邀请了其中一人是以前的同事，现在在微软中国。他有着对微软的强烈认同感、荣誉感，对dotnet的技术体系也非常熟，一整套分析方法分析下来，大家填写评估表的时候基本都选择了Dotnet...

到场的Java开发者，缺少架构师级的能力，所以被比下去了；另外让我感到困惑的是：似乎使用Java同时做B/S版和C/S程序的公司并不太多？大多使用Java更多聚焦在Web模式的开发上，做Web开发使用的技术又不尽相同，即使选择了Java，还得在一堆Web框架里进行选择...

请大家继续大力支持！（看完了，给出宝贵意见啊～～）

公司在北京，有能力有时间的朋友想提供技术支持的话，欢迎与我联系 ！

@Fantasysoft

“各种各样的技术都有它所适合的应用场景”，说得好！
本文虽然也描述了一个业务场景，只是之后的评估并没有直接针对这个场景的关键决定因素来展开－－仅仅是对几个因素的宏观对比，这几个对比的结果，仅仅让我亲Java而远Dotnet。

如果是中小型的 Web 应用，Rails 是一个很好的方案；重新学习没有你想的那么可怕

存在即是真理，评估优劣似乎意义已不大。各种各样的技术都有它所适合的应用场景，否则它会被历史淘汰的。

我更期待不同的技术能够相互学习，相互借鉴，毕竟尊重对手是很重要的。

.NET社区力量不够，我就要尽我的力量提高它，完善它
.NET创新不够，我就更努力地提高，更多创新，让更多新思想从.NET社区产生，让JAVA社区来学习
.NET有这样那样的缺陷，我们的职责就是努力改变这样的现状。

.NET不行我们的目标就是让他行！不是转投JAVA。为什么？所有JAVA能举出的好处都是别人努力和创新的结果，只是选择和学习没有成功的可能。不可能复制成功

把开发工具升高到这么高的高度的，也只有程序员了
从用户的角度，考虑的是价格和开发周期
谁在乎你用什么

另外对于楼主想让我转发本文到cnblogs上的意见， 我倒是想让大家看到这篇文章，不过cnblogs首页不提倡转贴，所以有3个方法：
1. 在我的下篇随笔中给出本文的连接(最近可能会写一篇有关soa的随笔)
2. 楼主到cnblogs注册 一个账号，然后发布该文
3. 让dudu转一下 :)

BTW: 个人比较头疼这种背景，字又很小 看得眼花了 :S

可以看出楼主在这篇文章上花了不少功夫，文章也确实不错。

首先我先回避文章最后提到的问题，来评价一下文章的内容


---
博客园,专著于.net技术的blog社区
MSDN Home
MSDN中文网站



中文
BlogJava http://www.blogjava.net/
Java视线论坛 http://forum.javaeye.com/index.php
Matrix http://www.matrix.org.cn
J道-专业的Java解决之道 http://www.jdon.com/
Java爱好者http://www.javafan.net/index.jsp
BEA dev2dev 在线 http://dev2dev.bea.com.cn/
IBM developerWorks 中国 http://www-128.ibm.com/developerworks/cn/java/index.html
http://www.javaresearch.org Java相关技术综合服务网站
http://www.javaworld.com.tw/jute/index.html
----

从以上的数据来看，.net社区在国内是多么的弱小。

---
学习曲线

Dotnet入门容易，有着从服务器到开发工具的一站式解决方案；Java的入门曲线则相对较高，N多的技术、开源框架要掌握、要选择，服务器、开发工具的顺利使用要做很多的配置工作。
对于企业级开发而言，其关键在于满足业务要求，合理的设计方案和架构，设计模式等，这些无论对于Java或Dotnet都是非常重要的。使用Java来学的话，由于整个社区对于架构、设计模式的普及，提升会比dotnet快。
---
再配合这段话， 更加催发我得出一个建议:
如果你有很好的基础(聪明，经过了系统的学习) 那么我建议你从java开始你的程序设计之路。(assembly,c++暂且不谈)， 那样你会成长得很快。



从ms对待nunit, nant的态度来看， 如果你想在developer的市场上和ms竞争， 那么或许结局会很惨， 无数的历史证明了这一点， 在.net平台下可能不久将上演的一场 JetBrains vs MS 好戏。

但是如果你开发的是特定领域的应用(中国软件公司通常做的是这个)， 似乎不会和ms发生竞争，而且他还会对你提供帮助。所以这种遭ms打压的问题，对于大部分中国公司来说应该是不存在的。



---
举例描述：首先用Java(或C#)搭建企业应用框架，该框架包含认证/权限/组织角色管理、文件管理等通用性的功能。然后在该框架的基础上把现存C/S版的－－PB实现的财务管理系统，Delphi实现的库存管理系统，VC实现的局域网即时通讯系统的业务功能模块全部用Java或(C#)重写，并增加B/S版本的实现。
---
This is nearly impossible for us! 其实这里搂主提出了一个对遗留系统的整合，对企业内部应用和企业外部应用整合的想法。 有这种想法也不足为奇， 这也是最近SOA火热的原因， 不管在java还是在.net社区(国外) SOA都是最近很热的一项技术。

最近刚好看到IBM的征文：
http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/0fd9b681aadeffa1852570cf005fdc06?OpenDocument



Now focus on the last question:

我建议采用的平台是：(Java/Dotnet/其它)
java .net 让他们做各自擅长的领域，让开发team选择自己熟悉的语言。

我的理由是：...
集成，整合 不能靠统一一个框架来实现， 这样你最多解决了企业内部的问题，而且重新实现原有的系统也是投资者所不能接受的。

应该让SOA在其中发挥更大的作用。

我的补充意见：...
如果你有很好的基础(聪明，经过了系统的学习) 那么我建议你从java(而不是.net)开始你的程序设计之路。(assembly,c++暂且不谈)， 那样你会成长得很快。

根据weide最近的这个回复：
"其中核心问题：作为一家行业软件提供商，要形成自己的企业应用框架[6]，并在该企业应用框架上搭建行业的整体解决方案。也就是把各个系统中共性的、普遍性的问题提取出来，形成“企业应用框架”。其它的业务功能，用同一开发平台重新实现为业务功能模块。最后通过企业应用框架和业务功能模块，组装成产品系列。"

那我推荐你采用java
理由：要形成自己的企业应用框架，那么必须自己能够根据框架的需求做出特定的框架，这个在.net上的实现难度远远大于java，而且.net的更新势必影响到整体框架的建设，而在java中则不是如此。
Java界的开源产品确实众多，但以思想角度考虑则大多相同，只是在框架级别上各自有自己特性的地方，相对.net而言，有得选择就比没得选择好。
以中小型企业项目这个角度去讲的话，我觉得采用哪种技术都无所谓，但想要形成一个自己公司的统一框架的话，java的优势无疑可以得到极大的发挥，但前提条件是有投入此框架研发的决心，如果没有的话，.net仍是首选，毕竟.net相当于已经提供了一套框架。
另外一个角度就是从服务器端操作系统的竞争去阐述，这个角度去看仍然认为unix占有绝对的优势，从这样的角度的话无疑选择java对于企业会更为有利。

@非鱼

Sorry,是我误导了你，修改了Blog中关于业务场景描述的部分。

其中核心问题：作为一家行业软件提供商，要形成自己的企业应用框架[6]，并在该企业应用框架上搭建行业的整体解决方案。也就是把各个系统中共性的、普遍性的问题提取出来，形成“企业应用框架”。其它的业务功能，用同一开发平台重新实现为业务功能模块。最后通过企业应用框架和业务功能模块，组装成产品系列。

关于你上面提到的几个问题，由于现在我们服务的主要客户是中小企业，所以关于工作流等，考虑使用免费的方案；数据挖掘，以前没用，近期也没有打算...

@weide

Oh, Either you misleaded me or I miunderstanded you.

Forget it. I think the platform choice mainly depends on the system scale. Of couse you should think about other issues. As I know (from friends), there's no successful Enterprise Level system (I mean very large scale) on .net platform. Try to identify your system scales:

1. Is it a information collecting/organizing/OLAP system?
2. Are you preparing to use Workflow in the coming system?
3. Do you have any complex business process?
4. Is it a real distributed system?
5. Are the customers mature with IT, could they make full/less use of IT technology to help themselves?

First of all, you should try to manage system change, then complexity. Also find out what design level you are in may help you to do better.

Besides, environment influence may not be ignored and should be pay more attention to.

@非鱼

我想是“解决企业信息化中的信息孤岛，形成统一的整体解决方案”这句话，使你认为我应该focus on Enterprise Application Integration than technology choice

实际上，我这句话并不是通常所言“信息集成”，和EAI关系也不大。我说的信息孤岛，是指我们现在几个产品之间，互相独立，各自有自己的组织机构和权限管理，开发语言又各不相同，这带来的问题是：我们需要用不同的开发工具（开发语言）维护多套产品中的组织机构和权限管理，多次重复劳动；且代码模块不能很方便的被新的系统所重用。

现在要做的工作是，把PB写的产品A使用Java(或C#)重写,把用Delphi写的产品B也使用Java重写，把VC写的产品C同样也使用Java重写，同时把各个产品共用的模块，比如组织机构、权限管理等，只要维护一份代码就OK了。为企业实现定制功能的时候，由于全部功能模块都是由同一语言实现的，所以可以灵活组装成满足企业多个要求的“整体解决方案”。

Do I make sense?

@临海观潮

Excellent perspective. I thought about it but forgot to wrote them down. Many cases, when you finished a system, you may find that marketing was more important than what you thought before. Since it do act an important role while developing, you should think about it, at least ask someone to do that.

好吧，说两句

我建议采用的平台是：java
我的理由是：当你面临众多选择的时候，那既是痛苦，也是欢乐，当你被ms绑架的时候，只有痛苦。
我的补充意见：虽然大家对hibernate评价很高，我也对它评价很高，但我仍然觉得它的配置过于烦琐了，ruby on rails的约定大于配置的思想是很值得学习的，为什么没有人做一个hibernate on rails呢。。。

单纯比较语言的优劣意义不大，针对特定的问题都能够找到合适的解决办法，这个解决问题取决于开发人员应用语言的能力而不是语言的本身。
从风险驱动的角度考虑，个人感觉选择架构需要首先要考虑的是公司自身开发人员的的专长和公司的外部合作伙伴关系，比如和微软有非常好的合作关系应该首选.net，这样可以获得长期的价值保证。团队的开发能力也是重要的方面，如果都熟悉.net的话选择.net项目成功的可能性高。
如果单从技术性角度考虑还是考虑未来系统的应用领域，大型的应用系统J2EE的成功经验多，相对风险小，此外相关的平台选择性比较多，使得最终产品/平台可以给用户提供多种价格选择。如果有跨平台的要求应该优先考虑J2EE。

Glad to see your awesome work. :)

Personaly, I think your article put too much energy on technical matter. But actually far from what you want. Maybe you should focus on Enterprise Application Integration than technology choice.

From now, I can't see which tech is more suitable to your situation. Please check your problem and your purpose. I don't think they are corresponding to each other.

Legacy apps mostly did not use component technology, thus you must think about to integrate them on persistence level. while you want them to be used continuiously, you should think of collecting information to build a publishing system, unless you are ready to replace them, do not focus on concrete technology/platform by now.

你先把日历隐藏吧,我们尽快处理一下。

弄好了，加了个链接显示大图

另：很奇怪，我选的界面风格在firefox下面显示的日历不大正常：（

宽度太大, 影响了首页的显示, 希望能调整一下, 或者使用摘要方式发布。

gz