我考虑是在原SERVER外封装一个WEB层，WEB层与SERVER间采用原CLIENT与SERVER之间通信接口，这样只需要重新写WEB层，能够改动最小化。
还有一种是WEB层直接操作数据库，操作同时通知SERVER更新数据库信息，这样需要修改SERVER和数据库表结构。
以上2种感觉还是有缺陷，请做过类似系统的朋友指点，谢谢。
23 个解决方案
#1
实际上楼主的做法仍然是C/S模式，只是多个WEB层。
#2
改动最小就是用activex方式。
#3
1楼：不错，还是假的BS，但是时间不允许我重新设计和开发，只能基于CS的程序改，简单点说，这个CS系统开发40人月，现在我只有15人月的时间来改。
2楼：ACTIVEX的方式开发量也不小，简单点说，实现一个WORD的 WEB版，得把多少东西都封装到ACTIVEX里面。
感谢2位回复，有好的思路继续讨论。
2楼：ACTIVEX的方式开发量也不小，简单点说，实现一个WORD的 WEB版，得把多少东西都封装到ACTIVEX里面。
感谢2位回复，有好的思路继续讨论。
#4
主要代码封装成COM,剩下的部分调用就行了,不过工作量还是不小
#5
两种是不同的东西- -~改有何意义? 没什么太大的关联 , 知道程序逻辑直接写web很快的.
#6
写个COM，把你的程序窗口加载进去就行了
这样可以解决问题吧？！
不过界面看起来还是跟原来一样，不知道满足不满足需求，如果连界面也要改，那就趁早重写吧
这样可以解决问题吧？！
不过界面看起来还是跟原来一样，不知道满足不满足需求，如果连界面也要改，那就趁早重写吧
#7
有那个必要么 要知道用vc写程序很复杂的 - -，可以做N多个同样的web了
#8
to akirya :你的意思是将原通信接口封装为COM，重新写WEB界面调用COM？
to jourbin :你的意思是否和akirya一样？但是如果直接加载原界面，看起来没什么太大区别。
我的想法是WEB的界面部分肯定需要重新写，这样至少从风格上是BS的样子。关键是后台的WEB SERVICE如何与现有的SERVER交互。刚才2位的建议我觉得不错，用COM应该比较容易实现两个的整和。
请路过的朋友都发表发表意见，谢谢。
to jourbin :你的意思是否和akirya一样？但是如果直接加载原界面，看起来没什么太大区别。
我的想法是WEB的界面部分肯定需要重新写，这样至少从风格上是BS的样子。关键是后台的WEB SERVICE如何与现有的SERVER交互。刚才2位的建议我觉得不错，用COM应该比较容易实现两个的整和。
请路过的朋友都发表发表意见，谢谢。
#9
再增加一个中间层, 负责适配Server和Web。
也就是将Web这边的请求进行解释为原来Client发送给Server的请求。
这样Server不用修改，Web端简单画些界面，调用中间层的接口。
当然中间层可以有很多技术可以选择，Com也行。
也就是将Web这边的请求进行解释为原来Client发送给Server的请求。
这样Server不用修改，Web端简单画些界面，调用中间层的接口。
当然中间层可以有很多技术可以选择，Com也行。
#10
建议还是使用一个WEB层，做一个WebServer端的COM接口，这个接口使用原来的Client通信底层，网页服务器端代码调用这个COM组件。
Browser---WebServer
|
COM组件(同时也是Client通信底层)--------Server---------Database
Browser---WebServer
|
COM组件(同时也是Client通信底层)--------Server---------Database
#11
如果界面要重新写，那就没什么好说的了，直接把CLIENT的功能封装成COM接口，另外一个工作是WEB写界面了，另加调用COM接口
因为界面重写，WEB界面，调用，显示肯定少不了
下面COM肯定是要的，除非你原来的SERVER也不要了，相当于全部重写
开始动手吧，我看来是没有更好的解决方案了
楼下有更好的话，我也要看看
因为界面重写，WEB界面，调用，显示肯定少不了
下面COM肯定是要的，除非你原来的SERVER也不要了，相当于全部重写
开始动手吧，我看来是没有更好的解决方案了
楼下有更好的话，我也要看看
#12
咨询了一些朋友，有人推荐我使用.net remoting来编写接口，asp.net写界面，这样兼容CS和BS，SERVER还能大量重用。有没有熟悉的朋友介绍一下这个方案的难点。本人对.net不是很熟悉，多年一直使用C++，据说这个需要使用C#，需要学习那些知识？
#13
个人觉得10楼的方案比较适合楼主。
另外是否也可以考虑利用VC.net，在WEB server 开发ASP.NET服务和现有的Server程序通讯，并向客户端提供数据？
继续关注该问题。。。
另外是否也可以考虑利用VC.net，在WEB server 开发ASP.NET服务和现有的Server程序通讯，并向客户端提供数据？
继续关注该问题。。。
#14
中间层可考虑用ISAPI Extension来实现.
#15
中间层可考虑用ISAPI Extension来实现.
#16
chehw 能不能展开说一下
#17
如果Web服务器用的是IIS, 可以通过ISAPI响应Web请求, 在后台处理后, 将结果返回给客户端(也可以不返回任何信息 -- 304 NO RESPONSE).
由于ISAPI是以C/C++的方式来实现的, 因此可以充分发挥C/C++的优势, 几乎可以以最优的性能来实现任何想要的功能(包括用COM/.NET实现不了或较难实现的功能).
对于基于IIS的Web开发来说, ISAPI是一种相对底层的技术, COM或.NET方式可以实现的, 实际上用ISAPI均可实现(更灵活且性能要高出很多),不过入门的门槛相对较高, 且调试起来较为困难. 除熟练掌握C/C++/win32 sdk外, 至少对CGI及HTTP协议有一定的了解才可以.
实际的应用例子可参考microsoft virtual server 2005 R2对虚拟机管理的实现方式.
由于ISAPI是以C/C++的方式来实现的, 因此可以充分发挥C/C++的优势, 几乎可以以最优的性能来实现任何想要的功能(包括用COM/.NET实现不了或较难实现的功能).
对于基于IIS的Web开发来说, ISAPI是一种相对底层的技术, COM或.NET方式可以实现的, 实际上用ISAPI均可实现(更灵活且性能要高出很多),不过入门的门槛相对较高, 且调试起来较为困难. 除熟练掌握C/C++/win32 sdk外, 至少对CGI及HTTP协议有一定的了解才可以.
实际的应用例子可参考microsoft virtual server 2005 R2对虚拟机管理的实现方式.
#18
个人觉得ISAPI要比ASP.NET难得多。
感觉还是用ASP.NET方便。
楼主对C++很熟悉，学起C#应该也很快。楼主只需要重点学习C#中的web form部分应该就可以了。
另外再在服务器端自制一些控件实现和原有的Server通讯即可。
至于和原有的server通讯是否一定采用.NET Remoting这个问题没想好。
总之，这几天仔细考虑了一下，觉得楼主在12楼提到的那个朋友的建议不错。
感觉还是用ASP.NET方便。
楼主对C++很熟悉，学起C#应该也很快。楼主只需要重点学习C#中的web form部分应该就可以了。
另外再在服务器端自制一些控件实现和原有的Server通讯即可。
至于和原有的server通讯是否一定采用.NET Remoting这个问题没想好。
总之，这几天仔细考虑了一下，觉得楼主在12楼提到的那个朋友的建议不错。
#19
感谢 chehw 的建议！
经过比较，最终决定采用ASP.NET来写，毕竟整个项目组都是 VC++开发人员，转型C#比较容易，特别是项目时间很短的条件下。
china_bai 应该对这方面比较在行，能不能帮忙分析一下工作量和难点，如果有类似的范例能否发给我一份学习一下。万分感谢！
经过比较，最终决定采用ASP.NET来写，毕竟整个项目组都是 VC++开发人员，转型C#比较容易，特别是项目时间很短的条件下。
china_bai 应该对这方面比较在行，能不能帮忙分析一下工作量和难点，如果有类似的范例能否发给我一份学习一下。万分感谢！
#20
我觉得先分析一下 服务器 实现的逻辑到底复杂不复杂，如果真的很复杂的话，我建议把server改成com组件给.net调用。如果不复杂的话，直接用.net实现逻辑就够了。vc++转C#是很快的，以前做过。
#21
webserivce
#22
感谢各位 结帖
#23
同样的问题 学习
#1
实际上楼主的做法仍然是C/S模式，只是多个WEB层。
#2
改动最小就是用activex方式。
#3
1楼：不错，还是假的BS，但是时间不允许我重新设计和开发，只能基于CS的程序改，简单点说，这个CS系统开发40人月，现在我只有15人月的时间来改。
2楼：ACTIVEX的方式开发量也不小，简单点说，实现一个WORD的 WEB版，得把多少东西都封装到ACTIVEX里面。
感谢2位回复，有好的思路继续讨论。
2楼：ACTIVEX的方式开发量也不小，简单点说，实现一个WORD的 WEB版，得把多少东西都封装到ACTIVEX里面。
感谢2位回复，有好的思路继续讨论。
#4
主要代码封装成COM,剩下的部分调用就行了,不过工作量还是不小
#5
两种是不同的东西- -~改有何意义? 没什么太大的关联 , 知道程序逻辑直接写web很快的.
#6
写个COM，把你的程序窗口加载进去就行了
这样可以解决问题吧？！
不过界面看起来还是跟原来一样，不知道满足不满足需求，如果连界面也要改，那就趁早重写吧
这样可以解决问题吧？！
不过界面看起来还是跟原来一样，不知道满足不满足需求，如果连界面也要改，那就趁早重写吧
#7
有那个必要么 要知道用vc写程序很复杂的 - -，可以做N多个同样的web了
#8
to akirya :你的意思是将原通信接口封装为COM，重新写WEB界面调用COM？
to jourbin :你的意思是否和akirya一样？但是如果直接加载原界面，看起来没什么太大区别。
我的想法是WEB的界面部分肯定需要重新写，这样至少从风格上是BS的样子。关键是后台的WEB SERVICE如何与现有的SERVER交互。刚才2位的建议我觉得不错，用COM应该比较容易实现两个的整和。
请路过的朋友都发表发表意见，谢谢。
to jourbin :你的意思是否和akirya一样？但是如果直接加载原界面，看起来没什么太大区别。
我的想法是WEB的界面部分肯定需要重新写，这样至少从风格上是BS的样子。关键是后台的WEB SERVICE如何与现有的SERVER交互。刚才2位的建议我觉得不错，用COM应该比较容易实现两个的整和。
请路过的朋友都发表发表意见，谢谢。
#9
再增加一个中间层, 负责适配Server和Web。
也就是将Web这边的请求进行解释为原来Client发送给Server的请求。
这样Server不用修改，Web端简单画些界面，调用中间层的接口。
当然中间层可以有很多技术可以选择，Com也行。
也就是将Web这边的请求进行解释为原来Client发送给Server的请求。
这样Server不用修改，Web端简单画些界面，调用中间层的接口。
当然中间层可以有很多技术可以选择，Com也行。
#10
建议还是使用一个WEB层，做一个WebServer端的COM接口，这个接口使用原来的Client通信底层，网页服务器端代码调用这个COM组件。
Browser---WebServer
|
COM组件(同时也是Client通信底层)--------Server---------Database
Browser---WebServer
|
COM组件(同时也是Client通信底层)--------Server---------Database
#11
如果界面要重新写，那就没什么好说的了，直接把CLIENT的功能封装成COM接口，另外一个工作是WEB写界面了，另加调用COM接口
因为界面重写，WEB界面，调用，显示肯定少不了
下面COM肯定是要的，除非你原来的SERVER也不要了，相当于全部重写
开始动手吧，我看来是没有更好的解决方案了
楼下有更好的话，我也要看看
因为界面重写，WEB界面，调用，显示肯定少不了
下面COM肯定是要的，除非你原来的SERVER也不要了，相当于全部重写
开始动手吧，我看来是没有更好的解决方案了
楼下有更好的话，我也要看看
#12
咨询了一些朋友，有人推荐我使用.net remoting来编写接口，asp.net写界面，这样兼容CS和BS，SERVER还能大量重用。有没有熟悉的朋友介绍一下这个方案的难点。本人对.net不是很熟悉，多年一直使用C++，据说这个需要使用C#，需要学习那些知识？
#13
个人觉得10楼的方案比较适合楼主。
另外是否也可以考虑利用VC.net，在WEB server 开发ASP.NET服务和现有的Server程序通讯，并向客户端提供数据？
继续关注该问题。。。
另外是否也可以考虑利用VC.net，在WEB server 开发ASP.NET服务和现有的Server程序通讯，并向客户端提供数据？
继续关注该问题。。。
#14
中间层可考虑用ISAPI Extension来实现.
#15
中间层可考虑用ISAPI Extension来实现.
#16
chehw 能不能展开说一下
#17
如果Web服务器用的是IIS, 可以通过ISAPI响应Web请求, 在后台处理后, 将结果返回给客户端(也可以不返回任何信息 -- 304 NO RESPONSE).
由于ISAPI是以C/C++的方式来实现的, 因此可以充分发挥C/C++的优势, 几乎可以以最优的性能来实现任何想要的功能(包括用COM/.NET实现不了或较难实现的功能).
对于基于IIS的Web开发来说, ISAPI是一种相对底层的技术, COM或.NET方式可以实现的, 实际上用ISAPI均可实现(更灵活且性能要高出很多),不过入门的门槛相对较高, 且调试起来较为困难. 除熟练掌握C/C++/win32 sdk外, 至少对CGI及HTTP协议有一定的了解才可以.
实际的应用例子可参考microsoft virtual server 2005 R2对虚拟机管理的实现方式.
由于ISAPI是以C/C++的方式来实现的, 因此可以充分发挥C/C++的优势, 几乎可以以最优的性能来实现任何想要的功能(包括用COM/.NET实现不了或较难实现的功能).
对于基于IIS的Web开发来说, ISAPI是一种相对底层的技术, COM或.NET方式可以实现的, 实际上用ISAPI均可实现(更灵活且性能要高出很多),不过入门的门槛相对较高, 且调试起来较为困难. 除熟练掌握C/C++/win32 sdk外, 至少对CGI及HTTP协议有一定的了解才可以.
实际的应用例子可参考microsoft virtual server 2005 R2对虚拟机管理的实现方式.
#18
个人觉得ISAPI要比ASP.NET难得多。
感觉还是用ASP.NET方便。
楼主对C++很熟悉，学起C#应该也很快。楼主只需要重点学习C#中的web form部分应该就可以了。
另外再在服务器端自制一些控件实现和原有的Server通讯即可。
至于和原有的server通讯是否一定采用.NET Remoting这个问题没想好。
总之，这几天仔细考虑了一下，觉得楼主在12楼提到的那个朋友的建议不错。
感觉还是用ASP.NET方便。
楼主对C++很熟悉，学起C#应该也很快。楼主只需要重点学习C#中的web form部分应该就可以了。
另外再在服务器端自制一些控件实现和原有的Server通讯即可。
至于和原有的server通讯是否一定采用.NET Remoting这个问题没想好。
总之，这几天仔细考虑了一下，觉得楼主在12楼提到的那个朋友的建议不错。
#19
感谢 chehw 的建议！
经过比较，最终决定采用ASP.NET来写，毕竟整个项目组都是 VC++开发人员，转型C#比较容易，特别是项目时间很短的条件下。
china_bai 应该对这方面比较在行，能不能帮忙分析一下工作量和难点，如果有类似的范例能否发给我一份学习一下。万分感谢！
经过比较，最终决定采用ASP.NET来写，毕竟整个项目组都是 VC++开发人员，转型C#比较容易，特别是项目时间很短的条件下。
china_bai 应该对这方面比较在行，能不能帮忙分析一下工作量和难点，如果有类似的范例能否发给我一份学习一下。万分感谢！
#20
我觉得先分析一下 服务器 实现的逻辑到底复杂不复杂，如果真的很复杂的话，我建议把server改成com组件给.net调用。如果不复杂的话，直接用.net实现逻辑就够了。vc++转C#是很快的，以前做过。
#21
webserivce
#22
感谢各位 结帖
#23
同样的问题 学习