「winfrom与Java」winfrom框架
今天给各位分享winfrom与Java的知识,其中也会对winfrom框架进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
- 1、C#的WinForm编程和控件的使用与Java相比有哪些优点?
- 2、java怎么做winform?
- 3、winform调用java 写的webservice之
- 4、客户端是选择Java Swing还是C#Winform
- 5、谁来说说C#和JAVA
C#的WinForm编程和控件的使用与Java相比有哪些优点?
C#WinForm优点:
1.界面布局快且美观(控件很多),开发周期较短
2.自定义控件制作使用很方便(扩展性很强)
C#WinForm缺点:
1.可移植性比较差
2.需要.netframework支持
java怎么做winform?
Java不能做WinForm。
WinForm是微软VS套件中的,主要是用于C#语言。
而Java不是VS套件语言中的,所以不能使用WinForm。
winform调用java 写的webservice之
我晕厥,xml本来就是可以面向对象的啊。xml传的数据你直接可以转化成.net里的对象啊。用DataSet.ReadXml(Steam)就可以的啊。
客户端是选择Java Swing还是C#Winform
客户端是选择Java Swing还是C# Winform?
在某大型项目中,客户要求不能用浏览器作为客户端(即不能用B/S模式),而要采用桌面客户端的方式(服务端用SSH,客户端通过Web Service访问服务端应用,并且还要求能在客户端与服务端网络中断的情况下离线进行部分业务操作,例如查询)。这可给我们项目组提出了一个大问题:客户端应用开发的技术选型。
公司有些员工强烈建议用Java Swing,认为有一些框架可以利用,例如Spring RichClient(Swing),大家都对Spring比较熟悉,有亲近感;甚至可以考虑使用 Eclipse RCP(SWT),因为有Eclipse在前面作为成功标杆。并且公司开发人员绝大多是Java程序员,可以随时抽调精兵强将加入任务繁重的客户端开发中,解决技术难题,甚至突击编写普通业务功能。而C#人员要重新招聘,增加了很多不确定因素。
但是采用Swing,缺点是界面比较难看,控件少得可怜,对客户端资源的控制能力差,开发难度肯定高,并且公司内部也没有积累(Java程序员都是做B/S应用的),并且在人力资源市场上,Swing方面但凡有点水平的开发人员工资都高得吓人(在51Job上查了一下);但好处就是应用服务端与客户端都是用的Java,两边的人手可以灵活配置(当然前题是开发人员对于SSH和Swing都要能上手,一是需要一段时间学习,二是人家技能多了,肯定会要求加工资待遇的)。
并且Spring RichClient已经很久没有更新了,最新的版本是1.10,还是2009年6月发布的,在开发技术日新月益的今天,这种更新速度很叫人担心呀!难不成Spring组织已经放弃了这个子项目?!
另又看了一下Eclipse RCP,最近的更新是2009年8月的,也是叫人心里没有底呀!
而采用C# Winform,界面好看多了,界面控件也很丰富(MS自己的,第三方的都有很多),并且RAD开发平台是MS的绝对强项,客户端运行速度也不错,安装升级很方便,人力资源市场上应用有不少储备。但要在项目组是加入C#开发人员,对于合理组织人力资源有些不利。并且与服务端人员交流也肯定会存在问题。好在C#是Java之子,双方有太多相似的地方,交流起来难度应当没有想像得那样堪比楚河汉界。
关于运行环境方面的问题,下载一个Jre,大约15M;而下载一个.net Framework大约40M。看上去.net的运行环境比Java大得多,但是要注意,从XP Sp3以后所有windows操作系统已经在安装时集成了.net运行环境,也就是说,绝大部分用户是不用下载.net运行环境并安装的。
另外就是开发模式。在Java B/S应用开发中,一般是一个程序员从数据库、SSH到ExtJs全程贯通。好处是效率高,坏处是人员分工不明确,接口定义很随意。
在大型应用开发中,服务端与客户端的开发人员还是要分组比较好。服务端应当定义良好的接口,并且使用完备的测试用例保证其正确性与可用性。而客户端开发人员则着重于用户界面的处理,然后根据服务端的接口文档调用即可。
其实将服务端与客户端完全隔离开来也有其不利因素,就是人员交流成本会有相当程度的提高,服务端要为客户端定义明晰的接口方法,提供完备的接口文档,以方便客户端理解与调用,并且还要为自己的服务端写测试用例,以确保接口功能实现正确性。
但其有利因素也让人心动,就是提高了应用系统的模块化程度,逼迫设计人员精心划分模块、仔细设计接口,不象以前服务端(SSH)与客户端(ExtJs)都是一个人在做开发,很多本应当明确定义的接口,开发人员都只是按自己的意愿随意设计修改。同时,集成第三方应用时,也不用专门费时费力再开发接口,只是将已经设计实现的接口包装一下,加上权限等对第三方的限制条件即可。
我们公司作为一家以客户为导向的应用系统服务型公司,在技术上不应做太多、太深入研究,跟着主流和客户的要求走就没有错!现在服务端的主流是什么?Java(SSH)。客户要求客户端不用浏览器,要做成桌面应用,那现在桌面应用开发的主流是什么?C#WinForm(或者WPF)。桌面应用要求跨平台吗?不用。现在对外发布远程应用接口的主流是什么?Web Service,那我们服务端与客户端的通讯方式就只有采用Web Service。
看上去采用Java的长处很明显,短处也很明显,带来的风险也大。而C#一切都显得很中庸,但相应的风险也小。我们还是取中庸之道吧!Java Server+C# Client。
另外,根据同事提出的不同意见,有以下几点说明:
1、在网络上,开发人员公认C# Winform或者WPF的界面库肯定比Java Swing的丰富得多。可能是概率的问题,我们运气不好,正好没有找到,或者没有合适的人来进行这方面的工作;如果有可能,我们可以在下一步用WPF库(反正.net运行环境已经安装了);
2、在客户端,主要的工作是用户界面处理,这方面不会用到复杂的C#语法与语言特性,主要是对控件的使用(界面事件的响应代码占到60%以上),在这方面编程中,C#与Java在语法上的差别不是太明显,要求人员通吃两边的难度确实不大,对Java开发人员来说,主要是学习熟练使用VS界面及界面控件;
3、关于Web Service的问题,我觉得采用Json是一种选项,实际上.net中也有原生Json处理类。但采用文本方式传递对象产生很多摸名其妙的问题,例如我在服务端一个应用接口中加了一个字段,或者改了字段类型、长度,如果在客户端有几个功能都用到了这个接口,有的可能会正常使用,有的可能会报错,这样给客户端开发、调试及测试带了很多额外负担(困惑与不一致)。如果采用严格的对象接口,在调用时就会全部报错,实际上对开发工作更加有利。并且生成接口看似增加了工作量,实际上可以一次生成,多次使用,而Json格式可能会由各个客户端开发人员各自解析与理解,反而耽误时间,也更有可能出错(当然也可以写一个中间层,统一转换成对象接口,但增加了工作量及出错的可能性)。客户端Web Service接口的生成在VS中是很简单的,可能我们没有找到合适的方法吧?实际上客户端应当有专门的Web Service接口处理工作岗位来统一管理配置Web Service接口,生成桩代码、数据传输实体类及DLL接口库,并提交给其他开发人员直接调用即可,这也是分层开发的要求,不过我们现在没有设置这样的人员岗位而已,这也是我们组建结构合理的C#开发团队的要求之一。
4、因此,问题的根源还是在于人事。项目开始时,我们有成熟的Java框架,有熟练的开发人员,但在C#方面,没有成熟的框架,也没有开发人员,找了一两个新人就开始搭建如此重要的客户端技术框架,这完全是“事倍功半”的做法,但项目进度与人事安排的困难在那里,这也是没有办法的办法。如果一开始就能找到合格的C#的技术架构师,能带来成熟的框架(就象我们在Java服务端的),后面的问题都不会出现。
5、最后,值得高兴的是,现在客户端开发的最困难时期已经过去,不管架构好不好,我们的客户端框架已经建起来了,也已经开发了很多实际的应用功能,并且运行也算良好,这就是一个巨大的胜利。我相信,再过一段时间,客户端开发人员结构会日趋合理,框架也会稳定起来,好用起来,开发工作会越来越顺利。
谁来说说C#和JAVA
很多人说C#是微软用来和Java抗衡的武器,因为二者在很大程度上有着惊人的相似
,尽管如此,两者不同的地方也很多,所谓“于细微处见差异”。那么两者的相似和区
别都在什么地方呢?我们从今天开始,会从各个角度来对比C#和Java的特点,希望能对
正在学习、使用C#的朋友有所帮助。
1、C#和.NET平台的概貌
2000年6月,微软发布C#语言和.NET平台。C#语言是一种强类型的,面向对象的语言
,它具有语法简单、表达力强的特点,而.NET平台则是构成微软的“.NET计划”的基石
。
.NET平台的核心包括两方面,一方面就是著名的通用语言运行机(Common Language
Runtime),虽然这个名词起得晦涩了点,不过大家可以拿它和Java的虚拟机来作比较,
二者完成的任务大致相同;另一方面就是一大堆通用函数库,这些库函数可以被多种语
言调用,并且通过编译都产生一种共同的中间语言(Intermediate Language),这种语
言也可以拿Java的字节码来类比,虽然完成的方式有些不一样。
2、C#和Java
下面简单地把C#和Java的相似处列出来,虽然在这里我们重点讨论的是C#和Java的
不同点,但是了解一下二者的相同之处也是很有必要的。
二者都编译成跨平台的、跨语言的代码,并且代码只能在一个受控制的环境中运行
自动回收垃圾内存,并且消除了指针(在C#中可以使用指针,不过必须注明unsafe
关键字)
都不需要头文件,所有的代码都被“包(package)”限制在某个范围内,并且因为没
有头文件,所以消除了类定义的循环依赖
所有的类都是从对象派生出来,并且必须使用New关键字分配内存
用对象加锁的方式来支持多线程
都具有接口(interface)的概念
内部类
继承类的时候不会以某种特定的访问权限来继承;
没有全局函数或者常量,一切必须属于类;
数组或者字符串都自带长度计算和边界检查;
只使用“.”操作符,没有“-”和“::”;
“null”、“boolean”和“bool”成为了关键字;
任何变量均在使用前进行初始化;
不能使用整数来返回到if条件语句中,必须使用布尔值;
“Try”模块后可以有“finally” ;
3. 属性(Property)
属性的概念对大家来说应该是很熟悉的,类成员函数可以自由地访问本类中的任何
属性成员。不过若要从一个类中去访问另一个类中的属性,那就比较麻烦了,所以很多
时候我们使用Getxxx和Setxxx方法,这样看起来显得极不自然,比如用Java或者C++,代
码是这样的:
foo.setSize (getSize () + 1);
label.getFont().setBold (true);
但是,在C#中,这样的方法被“属性化”了。同样的代码,在C#就变成了:
foo.size++;
label.font.bold = true;
可以看出来,C#显然更容易阅读和理解。我们从这个“属性方法”的子程序代码中
,也可以看到类似情况:
Java/C++:
public int getSize()
{
return size;
}
public void setSize (int value)
{
size = value;
}
C#:
public int Size
{
get{return size;}
set{size = value;}
}
为了区分这种属性化的方法和类的属性成员,在C#中把属性成员称作“域(field)”
,而“属性”则成为这种“属性化的方法”专用的名词。顺便说一句,其实这样的属性
化方法在VB和DELPHI中是经常碰到的,在VB中它也就叫属性。
另外,在C#中Get和Set必须成对出现,一种属性不能只有Get而没有Set(在Java和
C++中就可以只有Get或者只有Set),C#中这样做的好处在于便于维护,假如要对某种属
性进行修改,就会同时注意Get和Set方法,同时修改,不会改了这个忘了那个。
4、对象索引机制(Indexer)
C#中引入了对象索引机制。说得明白点,对象索引其实就是对象数组。这里和上一
节中的属性联系起来讲一下,属性需要隐藏Get和Set方法,而在索引机制中,各个对象
的Get或者Set方法是暴露出来的。比如下面的例子就比较清楚地说明了这一点。
public class Skyscraper
{
Story[] stories;
public Story this [int index] {
get {
return stories [index];
}
set {
if (value != null) {
stories [index] = value;
}
}
}
...
}
5. 指代(Delegate)
指代这个玩意很特别,它有点象指针,但又不完全是,不过大家还是可以把它理解
为一种类型安全的、面向对象的指针。(什么是类型安全和面向对象就不用讲了吧?)
顺便提一句,有很多书上把Delegate翻译成代理,我觉得这样翻不够确切,翻译成“指
代”更恰当些,道理上吻合,并且还符合它的本来意思——微软本来就是用Delegate来
“取代指针”,所以叫“指代”,呵呵。
说起指代,也许至今Sun还会对它愤愤不已,为什么呢?因为在Sun的标准Java中是
没有这个东西的,它是微软99年发布的MSVJ++6添加的“新特性”。为此,两家公司吵得
不亦乐乎,并且还专门在网上写了大量文章互相攻击,有兴趣的朋友可以去看看(只有
英文版)。
话归正传,指代有什么特点呢?一个明显的特点就是它具有了指针的行为,就好象
从Java又倒回到了C++。在C#中,指代完成的功能大概和C++里面的指针,以及Java中的
接口相当。但是,指代比起C++的“正宗指针”来又要高明一些,因为它可以同时拥有多
个方法,相当于C++里面的指针能同时指向多个函数,并且是类型安全的,这一点体现了
它的“对象”特性;而比起Java的接口来,指代高明的地方在于它能可以不经过内部类
就调用函数,或者用少量代码就能调用多种函数,这一点体现了它的“指针”特性。呵
呵,很有“波粒二象性”的味道吧?指代最重要的应用在于对于事件的处理,下一节我
们将重点介绍。
6、事件(Event)
C#对事件是直接支持的(这个特点也是MSVJ所具有的)。当前很多主流程序语言处
理事件的方式各不相同,Delphi采用的是函数指针(这在Delphi中的术语是“closure”
)、Java用改编类来实现、VC用WindowsAPI的消息系统,而C#则直接使用delegate和ev
ent关键字来解决这个问题。下面让我们来看一个例子,例子中会给大家举出声明、调用
和处理事件的全过程。
//首先是指代的声明,它定义了唤醒某个函数的事件信号
public delegate void ScoreChangeEventHandler (int newScore, ref bool cancel)
;
//定义一个产生事件的类
public class Game
{
// 注意这里使用了event关键字
public event ScoreChangeEventHandler ScoreChange;
int score;
// Score 属性
public int Score
{
get {
return score;
}
set {
if (score != value)
{
bool cancel = false;
ScoreChange (value, ref cancel);
if (! cancel)
score = value;
}
}
}
// 处理事件的类
public class Referee
{
public Referee (Game game)
{
// 裁判负责调整比赛中的分数变化
game.ScoreChange += new ScoreChangeEventHandler (game_ScoreChange);
}
// 注意这里的函数是怎样和ScoreChangeEventHandler的信号对上号的
private void game_ScoreChange (int newScore, ref bool cancel)
{
if (newScore 100)
System.Console.WriteLine ("Good Score");
else
{
cancel = true;
System.Console.WriteLine ("No Score can be that high!");
}
}
}
// 主函数类,用于测试上述特性
public class GameTest
{
public static void Main ()
{
Game game = new Game ();
Referee referee = new Referee (game);
game.Score = 70;
game.Score = 110;
}
}
在主函数中,我们创建了一个game对象和一个裁判对象,然后我们通过改变比赛分
数,来观察裁判对此会有什么响应。
请注意,我们的这个系统中,Game对象是感觉不到裁判对象的存在的,Game对象在
这里只负责产生事件,至于有谁会来倾听这个事件,并为之作出反应,Game对象是不作
任何表态的。
我们注意到,在裁判类的Referee函数中,Game.ScoreChange后面使用了+=和-=操作
符,这是什么意思呢?回到我们定义ScoreChange的地方,可以发现ScoreChange是用ev
ent关键字修饰的,那么这里的意思就很明白了:ScoreChange是一个事件,而事件被触
发后需要相应的事件处理机制,+=/-=就是为这个事件增加/移除相对应的事件处理程序
,而且,并不是一个事件只能对应一个处理程序,我们还可以用这两个操作符为同一事
件增加/移除数个事件处理程序。怎么样?很方便吧!
在实际应用中,和我们上面讲的(竞赛-裁判)机制很相近的系统就是图形用户界面
系统了。Game对象可以看作是图形界面上的小零件,而得分事件就相当于用户输入事件
,而裁判就相当于相应的应用程序,用于处理用户输入。
指代机制的首次亮相是在MSVJ里,它是由Anders Hejlsberg发明的,现在又用到了
C#中。指代用在Java语言中的后果,则直接导致了微软和Sun之间对类和指针的关系产生
了大量的争论和探讨。有意思的是,Java的发明者James Gosling非常幽默地称呼指代的
发明者Anders Hejlsberg为“‘函数指针’先生”,因为Anders Hejlsberg总是想方设
法地把指针变相地往各种语言中放;不过有人在看了Java中大量地使用了各种类后,也
戏称Java的发明者James Gosling为“‘全都是类’先生”,真是其中滋味,尽在不言中
啊。
winfrom与Java的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于winfrom框架、winfrom与Java的信息别忘了在本站进行查找喔。
发布于:2022-12-27,除非注明,否则均为
原创文章,转载请注明出处。