问题描述
开发公司内部管理系统，综合考虑各方面因素，最后放弃B/S，采用C/S分布式开发。数据库服务器单独，放总部。分公司通过CLIENT，通过中间层访问数据库。但是我有疑问，中间层比如我用WEBSERVICE，我如何做部署？WEBSERVICE服务器我是放分公司本地好还是放总部好？WEBSERVICE除了作为一个通用访问数据库函数，具体还起到哪些具体作用？比如缓存怎么缓的？性能上怎么提高的？谢谢！！！
解决方案
解决方案二：
CSLA.NET框架不知道如何
解决方案三：
这个比较严重，sevice当然放总部，分公司有多个，你只要对服务器端做一次部署都可用嘛而且这个方式可以慎重，搞不好，性能，安全两个都没了，比较难控制，b/s多好
解决方案四：
webservice当时是发在总部的了！部署在总部服务器IIS上！现在不是都在网bs上转吗，咋弄成cs了！你可以学习下wcf，这是专门针对与分布式系统的！
解决方案五：
B/S的确是好，但是我们业务很复杂，用户对于操作性要求非常强大，当然B/S也可以做到，但是开发成本太高了。
解决方案六：
该回复于2011-09-14 10:24:29被版主删除
解决方案七：
我们之前系统就这么做的而且客户端还是delphi开发的ws放服务器端，只提供对一些数据库封装操作（比如一张数据表指定数据的下载上传操作）和用户校验等不适用ssl的话，ws基本上就是透明的，如果你打算提供直接的数据库操作类比如sqlhelper的ws功能，至少把sql语句进行加密后作为参数使用吧ws本身安全机制采用自定义SoapHeader和自己实现的用户令牌（类似CookieBasedSession）来实现的性能方面由于应用服务器只提供函数级应用，比一般的web服务器要好些页面级缓存之类基本上是不需要用到的，数据缓存就按照asp.net处理就行不过我们当时没用到另外，根据cpu核数配置web园数量，对性能提升比较大就这些了，希望有用
解决方案八：
我们当时也是客户端的操作太多所以只把数据交互的步骤用ws来做现在已经转向bs了花了一年多时间才改过来
解决方案九：
webservices提供了三个属性Namespace：此属性的值包含XMLWebService的默认命名空间。XML命名空间提供了一种在XML文档中创建名称的方法，该名称可由统一资源标识符（URI）标识。如果不指定命名空间，则使用默认命名空间http://tempuri.org/Name：此属性的值包含XMLWebService的名称。在默认情况下，该值是实现XMLWebService的类的名称。Description：此属性的值包含描述性消息，此消息将在XMLWebService的说明文件（例如服务说明和服务帮助页）生成后显示给XMLWebService的潜在用户这个也算webservices的作用吧
解决方案十：
引用4楼kebixiong111的回复:
B/S的确是好，但是我们业务很复杂，用户对于操作性要求非常强大，当然B/S也可以做到，但是开发成本太高了。
确实b/s性能的确比c/s好但是相对来说成本高很多其实LZ说的数据库放在总部还是分公司好这个问题这个要据情况而定
解决方案十一：
如果分公司和总部处于局域网，那怎么都好说，如果不是，webservice是必然的选择。上面都说了不少，至于安全性么，是必然要考虑的，比如说限制IP或者验证机制等等，我之前用的比较多的是动态口令的方式，原理就是提供一个初始化的口令，然后每次访问后都会生成一个新的口令给客户端，然后客户端下次调用时提供的口令不符合就拒绝。这个其实比较简单，但是也会存在局限性，例如如果知道初始密码以后就畅行无阻了，不过还好。因为不可能就这一个参数，另外的参数你可以传递复杂的内容，例如自定义的xml或者加密文件包，都可以
解决方案十二：
或者限制客户端mac或者绑定cpu一类更BT的方式……
解决方案十三：
引用9楼zyloveyrf的回复:
引用4楼kebixiong111的回复:B/S的确是好，但是我们业务很复杂，用户对于操作性要求非常强大，当然B/S也可以做到，但是开发成本太高了。确实b/s性能的确比c/s好但是相对来说成本高很多其实LZ说的数据库放在总部还是分公司好这个问题这个要据情况而定
++服务器当然放总部好，在这种系统来说还是B/S好点吧
解决方案十四：
引用12楼chenyingshu880603的回复:
引用9楼zyloveyrf的回复:引用4楼kebixiong111的回复:B/S的确是好，但是我们业务很复杂，用户对于操作性要求非常强大，当然B/S也可以做到，但是开发成本太高了。确实b/s性能的确比c/s好但是相对来说成本高很多其实LZ说的数据库放在总部还是分公司好这个问题这个要据情况而定++服务器当然放总部好，在这种系统来说还是B/……
说过了啊，B/S我也知道好啊，但是客户端操作要求很高。用B/S很难得到用户的使用要求。用户第一，用B/S还是C/S我们是做过详细调研才得出的结论，所以也不用告诉我B/S好，我也知道的。
解决方案十五：
引用楼主kebixiong111的回复:
中间层比如我用WEBSERVICE，我如何做部署？
只要是SOA，它必定是将服务器组放在一个相对隐蔽的位置，然后所有其它子系统都是访问这个系统的应用程序服务，而不是什么关系数据库。几乎可以说，在跨路由器的范围内，不考虑c/s数据库客户端。
解决方案：
如果你要用WEBSERVICE作为通用的数据查询，还不如直接使用SQLSERVER的XML查询，它可以通过HTTP访问。可以考虑使用邮件系统作为通信渠道，这样你们总公司和分公司可以物理上不直接相连，只要都可以收发邮件即可，可大大增加系统安全性，详细方案，请
解决方案：
webservice放在总部，不但可以处理访问数据库，还可以处理需要部署在服务器的其它逻辑。
解决方案：
引用楼主kebixiong111的回复:
WEBSERVICE除了作为一个通用访问数据库函数，具体还起到哪些具体作用？比如缓存怎么缓的？性能上怎么提高的？
从通讯角度，webservice只要是给业余开发人员使用的，它只能支持get/post类似的操作。而如果你要开发一个c/s通讯程序，其实往往需要考虑双向通讯，就好象一个最简单的网络游戏也要考虑双向通讯而不是什么webservice一样。真正的软件，大部分的设计核心都是活动，特别是真正好的软件总是对于Get和Push方式的信息操作的比例不会高于2:1的。简单地举例比如说有一些人正在讨论一个项目计划，那么这个场景中所谓的Get操作都有哪些？可能有人会说：“需要获取讨论组、获取这个讨论组的主管、获取它的管理员、获取它的成员、获取它的消息、获取谁在邀请别人、获取针对自己的邀请信息、获取别人随时加入或者退出讨论组的信息、获取讨论组的各种操作权限分配”等等。然而这个人肯定不是真正的做过通讯软件的设计者，而只是一个编写中国风格的OA程序的。很简单，比如说你给别人发一个短信，不是说你的手机把短信保存到移动公司的数据库里然后别人的手机去查询短信；你给别人打电话时其技术设计更不是什么在数据库中对音频数据的什么增删改查。再看上面的所谓Get操作，从c/s软件设计角度，很多都首先是“不落地”的，如果以很低的线程优先级保存到保存到数据库也是为了后备、或者计费、或者营业统计分析等等。当一个成员邀请别人，或者一个成员发送消息给大家伙，消息就直接推送到大家的桌面上了，而不管它是否保存到数据库中。就算是调用webservice方式，那么消息如何立刻广播到加入同一个讨论组的桌面应用程序上，以什么样的方式推送什么样的实体数据，这些要在你动手写代码之前设计好（而很多小软件作坊那样学点webservice概念于是就动手编写程序了，那么很快就会因为没有实际的通讯设计架构，于是又回到了c/s数据库增删改查的老路）。好，回到你的问题，webservice服务设计可以不可以不纠结于什么关系数据库表的增删改查？可以不可能有好一点的性能？答案是首先你要把它作为一个企业服务，让那种基于数据库操作的设计思维渐渐地丝毫不纠结在设计文旦中，然后才会逐渐学会基于更加专业的双工操作、长期稳定的通讯方式来设计所谓的“分布式”系统。
解决方案：
引用17楼sp1234的回复:
引用楼主kebixiong111的回复:WEBSERVICE除了作为一个通用访问数据库函数，具体还起到哪些具体作用？比如缓存怎么缓的？性能上怎么提高的？从通讯角度，webservice只要是给业余开发人员使用的，它只能支持get/post类似的操作。而如果你要开发一个c/s通讯程序，其实往往需要考虑双向通讯，就好象一个最简单的网络游戏也要考虑双向通讯而不是什么webservi……
很认真的读了你的话，我觉得可能我还是没表达清楚。现状是这样：集团有20个分公司，总部在上海，总部人最多，其他地方的分公司人相对较少。现在需要规划新系统，做数据统一，操作统一，管理统一。所以最终想用C#开发WINFORM程序来实现。至于为啥选择WINFORM不选择WEBFORM这个我就不啰嗦了，和公司业务有关系。所以我想做过的朋友指点下，这种怎么架构？能够实现访问效率比较好？
解决方案：
现成产品能轻松达到这效果。
解决方案：
引用19楼atgo的回复:
现成产品能轻松达到这效果。
什么产品？
解决方案：
米人了啊？
解决方案：
楼主有兴趣可以直接找我要邮件通信系统的源码，我们实现了远程更新客户局域网数据的功能。
解决方案：
错误,中间层肯定不能用webservice,要用remoting,webservice在频繁的增删改查,效率超慢,用微软的remting就可以解决这个问题,基本上不慢,安全和性能全部解决了,