关于MVC + WebService 的模式是否可行？

最新有个计划中的项目产品，想写成 
前端用asp.net MVC 所有对于数据库的操作，都用WebService 做业务接口，WebService再操作数据库，为什么要用WebService做中转接口呢，主要是想将数据服务与显示分开，将来可灵活的提供数据给其它语言或工具。
在网上查了查，没有发现有人这么设计，所以想请教一下，这种方式有问题吗？

解决方案 »

  1.   

    这样做可以实现业务需求。
    如果客户端是APP的话，传输数据比较大，而且数据格式固定为XML了，灵活性较低,APP客户端的话一般用web api作为服务接口,传输数据可以是XML也可以是JSON,较为灵活，身份验证也可以直接用Oauth2.0。
    如果是内部客户端，用WCF比较多
      

  2.   

    如果你换成.net mvc + webapi，那更好点。也没什么问题了
      

  3.   

    asp.net 程序本身直接调用你的增删改查操作（你的 webservice 内部调用的方法）就行了，不应该再绕一圈远程通讯。
      

  4.   

    有一个 BLL 层设计当然是很好的。BLL 层设计不应该局限于、纠结于”所有对于数据库的操作“。尽管可以用对于数据库操作作为前端设计的隐喻，但是前端应该不知道服务器端用没用数据库、用了几种或者几个数据库、用了其它什么SOA服务，前端 Model 应该基于持久化来建模。好比如说移动运营商网络负责将一个手机的语音传统到几千公里的另一个手机，那么语音就是要处理的数据模型，网络负责路由，同时负责认证手机号码和为通讯计费、扣费等等。一个软件不能从什么数据库增删改查概念来向上揣摩用户需求（尽管许多做了很多年设计的人习惯于这种思维方式），否则创意就太狭隘了。软件 Model 设计要从前端需求出发，BLL 层的 Model 也是来自于前端需求的。前端要访问某一个服务，要输入输出，那么不管其同一个 Model 涉及到后台数据库的十几个数据库表，也仍然是要设计为一个高内聚的 Model 实体类型。所以数据库实际上是很低级的实现概念，而整个系统前端模型的持久化才是目的。这是不一样的。设计 Service 的时候并不假设一定有什么数据库表，而是要以前端为主来提出数据持久化需求。
      

  5.   

    你说的 webservie，或者 WCF 或者 WebApi 之类的，或者其它接入格式，都是一个 c# 格式封装而已。比如说以 udp 方式来接收同样格式的数据。所以不同的各种通讯形式，都要调用同一层 BLL 代码。而你的 asp.net 应用如果本身就是你的业务服务网站，那么你的 asp.net 应用就不应该再来调用什么 webservice 了。你的 webservice 只应该给别的应用用，自己不用。
      

  6.   

    asp.net MVC (包括 MVVM) 完成的是廋客户端任务（虽然也有人非要把他弄成富客户端的）
    WebService 完成的是富客户端任务的服务端
    自然不会有人把两者生拉硬套在一起WebService 通过 SOAP 实现服务端调用
    web api 实现的实际是 SOAP 的前身 PRC按照捏构想，你应该按 REST 的思路来打造你的系统，并在 asp.net 中强制自己使用 REST 的统一资源定位
      

  7.   

    我是想这么实现，webservice做为独立业务公用平台，将来会为其它各种子系统提供数据服务，而子系统也不单一的是asp.net ，也可能是WinForm，也可能是java，也可能是android或是IOS，也可能是硬件系统，很有可能这些子系统是并行的，这是一相低耦合的模块系统，我是但心这种模式下WebService是否能稳定运行，这种方式是否安全
      

  8.   

    另外在WebService端，我也在考虑是用EF 还是用低级点的 ado.net ，想来想去，还是想用ado.net，虽然写着麻烦点，但一切都是可控的，而且效率也高，我这种想法是否可行？
      

  9.   

    如果你的 webservice 就是跟你的 asp.net 网站在一起，那么你的 asp.net 直接调用 BLL 层的方法就行了，跟 webservice 客户端代理方式无关。为了”测试“一下能不能用，你可以在 asp.net 程序中使用 webservice 客户端代理来访问自己的服务，这就好像是一个人把自己家当旅馆一样还要登记一套手续、分配房间、做个套中人之类的形式化之后才敢上自己的床睡觉。这里关键变为在于 BLL 层设计。而不是用 webervice 封装。
      

  10.   


    这个问题没有说明你的背景，不好回答。你认为微软15年前推的框架跟那些 java 中的随便一个什么开源小框架一样是儿戏、版本混乱不兼容、没有认真测试、不是世界级的架构式设计、没有大规模应用背景是吗？不是的。webservice显然是可以用的。但是这只是从你的角度来回答。但是毕竟它是面向20年前的大型应用，在我看来今天是过度封装、不够灵活的产物。但是这跟你担心的是完全是两回事儿。并且实际上我们的产品在业务通讯中使用 tcp/websocket 为基本，这方面跟你的提问题的范围就根本不同，更是没法一致。
      

  11.   

    WebService 不是很简易，基于xml的soap协议不同的框架可能不一致 通用性并不好，可以提供类似的 restful-api 或者webapi 是个不错的法子。
      

  12.   

       
         你要区分全后端， .Net MVC 主控前后端， webservices完全主控后端。     
         你 MVC + WebService 是啥几把玩意？
         
      

  13.   

    看你应用大小，大中型项目建议你最好不用EF，执行复杂查询会出一些莫名其妙的问题，出现这些问题就只能用视图去解决，如果你本身就设计要使用大量试图也可。那建议你选 WebAPI + linq