FreeOZ论坛

标题: 有没有横跨.Net 和 J2EE的高手？ [打印本页]

作者: Coolioo 时间: 24-9-2007 17:00
标题: 有没有横跨.Net 和 J2EE的高手？
脚踩两只船的。.Net和J2EE样样精通？

是专攻一个平台呢？还是通吃？？那样对职业发展有好处？？

作者: hoopoos 时间: 24-9-2007 18:06
精通谈不上，但是我是先做了大概两年VB,VC，然后做J2EE的。当然专攻一个比较好，不过软件都是触类旁通的。数据结构，算法，分布式，事务，数据库，面对对象，基本的原理是一样的。

对职业发展有好处的是深入的思考和实践中的不断改进。和什么平台没关系，我没做过.Net，但给我三个月，我同样具备能deliver一个很好的.Net系统的能力，方法很重要，对需求进行模型化，找到类似的架构，然后模仿一个成功的案例，加上自己的refactor，就可以了。做多了，就不会被技术所拖累，如果一个技术很难掌握，那一般来说就不是个好的技术。

作者: Coolioo 时间: 24-9-2007 18:42
good point, mate

作者: Coolioo 时间: 24-9-2007 19:20
虽然大同小异，但是不同平台的构架也有区别。用的工具和类库都不一样。所以做到两者都熟练，也有一定的难度....

作者: monster2006 时间: 24-9-2007 23:08
楼主太贪心了点把，哈哈

精通另外一种平台的时间拿来玩多好，第一种用来赚玩的钱

作者: 西门吹哨 时间: 24-9-2007 23:19
“方法很重要，对需求进行模型化，找到类似的架构，然后模仿一个成功的案例，加上自己的refactor，就可以了”
都有成功案例可以找到来refactor吗

作者: dust76 时间: 24-9-2007 23:47
标题: 这个想法不实际
我做.NET的，虽然像项目管理，系统构架，开发模式之类的大的经验和方法论二者都可以类比，但是我觉得二者都精通不可能也不必要。

1 是会影响你对某种技术的熟练程度，什么工具2个月不用，工作的时候就得翻文档，工作效率就会下降50%
2 是和二者相关联的产品体系不一样。比如.net在以微软产品为主的项目里就有绝对优势，你会得到很多特别的好处，比如.net可以用C#编写和调试SQL Server 2005的存贮过程，在以存储过程为核心的模式里，开发效率和质量都可以提高一个数量级， WEB Service的两头都用.NET，客户端的类和代码都是自动生成的。但是在跑着AIX， HPUnix, Solarise 的大企业, .NET一点机会也没有。而这个大的技术环境，不管对于一个公司，还是你的个人学习，都经不起频繁变化的。

其实两种技术都有很旺盛的生命力，我相信，其中之一能佩得上“精通”二字，就不用担心会饿死了。

我觉得做技术的，固然要不断学习，但是要保护自己以前学习技术所花费的成本，我宁可去研究Flex, 也坚决回绝老板让我带JAVA团队的要求。

作者: usherlight 时间: 25-9-2007 00:08
以存储过程为核心？这在Java领域是不提倡的。运行效率有可能提高，开发效率和质量的提高是为什么？
存储过程的单元测试如何进行？后期维护如何保证？

作者: usherlight 时间: 25-9-2007 00:11
标题: 回复 #2 hoopoos 的帖子
我觉得衡量技术的好应该不是以是否容易掌握为标准吧。

作者: Frankman 时间: 25-9-2007 10:51

原帖由 usherlight 于 25-9-2007 00:08 发表

 登录/注册后可看大图

以存储过程为核心？这在Java领域是不提倡的。运行效率有可能提高，开发效率和质量的提高是为什么？
存储过程的单元测试如何进行？后期维护如何保证？

That's a good question, a very good question!

作者: hoopoos 时间: 25-9-2007 12:08
stored procedure is not scalable so it's not popular in J2EE

不好掌握的技术，不能算是个很好的技术，如果开发团队需要花费很多精力考虑business logic之外的诸如security, session, transaction, log之类的coding，这能算好的技术吗。好的技术应该是能让team专注于解决用户的functional requirement，而non-functional requirement应该有技术的build-in解决

作者: Coolioo 时间: 25-9-2007 16:37
那到底是选Java阵营呢？还是选Windows阵营？

我个人喜欢Java/Unix系多点，但现在做.Net，恐怕以后很难转到Java了

作者: Frankman 时间: 25-9-2007 22:14

原帖由 Coolioo 于 25-9-2007 16:37 发表

 登录/注册后可看大图

那到底是选Java阵营呢？还是选Windows阵营？

我个人喜欢Java/Unix系多点，但现在做.Net，恐怕以后很难转到Java了

You shouldn't care that much about platform, things like this are far more important: http://www.infoq.com/interviews/domain-driven-design-eric-evans

[ 本帖最后由 Frankman 于 28-9-2007 08:22 编辑 ]

作者: Coolioo 时间: 25-9-2007 23:15
Thnx dude, the website is very informative....

作者: beysup 时间: 26-9-2007 01:03
我曾经横跨DOS和MAC OS

作者: usherlight 时间: 26-9-2007 22:37
标题: 回复 #11 hoopoos 的帖子
技术的范围并不是一个很窄的圈子，OOAD如果作为一种技术的话，有多少人敢自称已经很好地掌握了？又有多少人认为OOAD不是一个很好的技术？其实很多东西是易学难精的。

作者: hoopoos 时间: 27-9-2007 11:55
sorry, but I don't think OOAD is a kind of technology
打个比方，球员的技术和阅读比赛的能力，是两回事。我的理解，技术是具体的实现，而OOAD是一种抽象的方法。一个完全不懂软件开发技术的人，不会写代码，不会调试，不会配置，也可以做OOAD。

作者: earthengine 时间: 27-9-2007 23:21
标题: 回复 #10 Frankman 的帖子
作为存储过程为核心开发模式的支持者，我认为这都不是问题。

1。单元测试，谁说存储过程不能单元测试？实际上，只要将每个存储过程完成的任务用契约编程的概念明确化，则编写测试用例也非常容易的。

2。后期维护，存储过程的后期维护有何特殊困难之处吗？以SQL Server为例，由于有一系列功能强大的工具如SQL Profiler等的存在，跟踪和调试存储过程绝对不会难。

我不知道这位朋友所指的困难何在，但以我的经验而言，维护和测试基于SQL的存储过程和其他语言并无区别。关键还是在于SQL和其它语言在概念上存在巨大差别，导致多数人不习惯用SQL的方式思考问题。但对于有经验的程序员，这不应当是个问题。

作者: Frankman 时间: 28-9-2007 08:18

原帖由 earthengine 于 27-9-2007 23:21 发表

 登录/注册后可看大图

作为存储过程为核心开发模式的支持者，我认为这都不是问题。

1。单元测试，谁说存储过程不能单元测试？实际上，只要将每个存储过程完成的任务用契约编程的概念明确化，则编写测试用例也非常容易的。

2。后 ...

No offence, you need more reading and thinking. Spend some time on ORM tools like Hibernate and read blogs by Jeremy Miller, Martin Fowler, Oren Eini, just name a few. Also don't forget have a look at Micrsoft's ORM tool - you know what I'm talking about. You see, even arrogant and stubborn Microsoft create its own ORM product. Just FYI, JPA has become industry standard in java. What have Microsoft done in this field so far? Nothing. Sometimes, I have to admit java community is more mature than .Net community in that sense, although I have been programming on .net since its first beta.

Ok, it's time for breakfast.

[ 本帖最后由 Frankman 于 28-9-2007 09:45 编辑 ]

作者: hoopoos 时间: 28-9-2007 13:07
stored procedure is not scalable

Unless you are developing a two tier system and you have the confidence that this system will not change the basic requirement, for example, the users will not increase, the maintaince job is very few, etc. In a word, if your system never face the scale problem you can use SP as much as you like.

But, in three tier system, when you need more database connection, and your overload on SP will increase, vertical scale with increase the CPU or MEM can relieve your DB server, but most of the time only horizontal scale is the suitable solution. Unfortunately the SP will be a headache for horizontal scale since SP and DB are tightly coupled

作者: freefly111 时间: 28-9-2007 13:23

原帖由 Frankman 于 28-9-2007 08:18 发表

 登录/注册后可看大图

No offence, you need more reading and thinking. Spend some time on ORM tools like Hibernate and read blogs by Jeremy Miller, Martin Fowler, Oren Eini, just name a few. Also don't forget have ...

You can also have NHibernate for .Net.
even NVelocity, Nant, Nunit, ...

[ 本帖最后由 freefly111 于 28-9-2007 13:35 编辑 ]

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/bbs/)