web规划设计解决扩展

Question

我最近刚刚接触这块工作。一般web现在都是采用MVC模式。但是现在resetfull也热了。考虑现在的web使用。我计划把数据库操作这块提取出来，把Model也提取出来。
将数据库操作这块做成一个控制台服务。可以放在任何一个位置。
这样的目的：
1.可以建立必要的优先权限，同时再次检查是否会全表查询，尤其是权限表，给出告警。
2.统计访问
3.服务器隔离，更快速
4.直接在数据库访问服务器上进行model转换，序列化传回。
5.在web服务端可以很方便的修改resetfull
6.web服务端代码更加清晰，可以调用方法或者发送SQL
7.调度资源
8.很方便的替换数据库
9.满足各种库的更新
10.数据库读写也方便分离
这里还有一个小细节，如果数据库访问服务和web服务在同一个机器，则可以通过内存共享来访问，更加优质，但是服务（代码）却是分离的。但是我不知道这样做是否真实和我考虑的有意义。或者违反了web开发设计的什么规则。
希望有经验的老码农，大神说说看法。
到目前，我看到MVC模式都没有分离，都是和web项目再一起实现的。

Answer 1

晕！看到这儿，我还以为是2006、07年的帖子。restful 其实是噱头，从来也没有真正实际成为什么工业规范用法。不过是一些论坛、帖子宣传得做了一波。

Answer 2

通常在自己设计开发的 BLL 层中，直接对数据库层调用。这个数据库层可以使用你自己选定的框架，或者自己开发的 SQLHelper 等等，这本身已经封装了所谓的“Model、权限、数据库改变”之类的含义。如果你要弄一个 web 服务来多出一层，这一层再来重复 BLL 中调用数据库层的代码，而 BLL 层来以“增删改查”的名义来访问这个多出来的一层，我看到这是增加了一倍的人力成本，吃力不讨好，暂时看不到多大必要性。

Answer 3

rest不是让你抽取数据库一层，是让你提供业务API（业务业务业务！！！）
对应Rest微软提供的是WebApi
替换数据库之类的数据库操作是底层的事情，更上层（MVC、WebApi）没任何关系，上层根本不需要知道底层是怎么持久化的

Answer 4

在你的服务层要访问关系数据库进行“增删改查、事务”，直接了当地访问数据库系统才比较好。不必再花费巨大的性能代价、业务代价（例如拆散了内聚性，甚至丧失了事务性）来搞 http 服务。除非是必要地分离。例如一个巨大的公司已经有上千后台开发人员、几十个服务团队了，甚至有的已经大到可以单独成立上市公司了，那么拆出去。但是也是以业务为出发点的。凡是满脑子只知道一点低级的纯技术的的，以这个来不断折腾架的，往往都没有什么好的效果。

Answer 5

我感觉，这个10点要素全都是空口白话啊。根本没看出什么内容。
你直接写webapi，就好了。楼主给我的感觉，就是拿出一堆东西准备忽悠老板啊。实则好像并没什么内涵

Answer 6

服务器端，如果你就是那么点儿规模的，那么你的 BLL 层直接访问关系数据库的命名管道协议或者TCP协议服务端口，这一通讯机制也是传送sql语句的，Controller 调用 BLL 业务逻辑层，而 BLL 调用 DAL 数据库驱动层。BLL直接调用数据访问库引擎，而不需要中间出来个什么 restful 通讯转换。何况你的 restful 功能远远丢失了关系数据库的许多基本功能，例如你的 restfull 怎么体现跨多个 sql 命令的数据库事务？

Answer 7

有人跟我讲讲restfull的put和delete有什么用吗？我感觉就是造作。用get，post不是挺好?
有人实现过put和delete，以及怎么将它和post从实用上分开的？

Answer 8

restful 非常地学术化，就好像专门发明一个中文学科来研究“回子一共有几种写法”一样，是将很简单东西搞得很复杂了。关键是，并没有成为工业标准，只不过在大学讲坛上、论坛上很时髦了一阵子。长期依赖，get 和 post 作为两种基本的特征被广泛应用。但是 put、delete、trace 等等并没有发现什么特别的价值。通常一个人要成为时髦明星，必须比别的不入流小明星努力50倍才可能成为明星，仅仅努力4、5倍只会陪钱赚吆喝而不能成为明星。同样道理，一个只是纠结一些“龟腚”的说法，仅仅凭个人爱好来支持其实现，没有实际工业价值，也不会真正成为规律。

Answer 9

另一个方面来说，大多数大公司之所以遵循别人制定的协议，必定是因为它的 post 是面向表达业务“行为”的服务信令的，而不是面向什么低级的“增删改查”信令的。比如说“我想让张三这个厨师给我煎两个鸡蛋再烤一根火腿肠”，那么这就是一个服务行为，并不需要落地到什么增删改查。对于满脑子只有增删改查的人，非要把任何自然而然的东西都说成是某某数据库的某个数据表的增删改查，其实是一种幼稚病的体现。绝大多数的通讯是正常人之间的不落地的通讯，数据库表只是用户低级的数据持久化备份的一种工具，并不是目地。比如说电信网络把语音流播放给某个手机扬声器，工程师就直接了当地说中间的核心技术，只有书呆子才会说什么“一方往关系数据库保存语言文件、而手机则去某某火星上的公共数据库去查询读取语音文件”这种话。所以通讯的核心是千变万化的行为需求（比如说 fuck），而不是统一到什么 put、delete、modify 这些上面。

Answer 10

可能我描述有点问题，其实现在一般是MVC+EF、我相当于把EF弄出来，另外做一个服务，支持数据库操作。web服务端把SQL发到数据库操作上，然后回传。这里主要是多了一层网络传输。但是可以很好治理数据库查询。现在的项目里面数据库包含了3种，redis,oracle,还有一种国产数据库，在web端操作麻烦。想直接放在一起。web服务端只管写SQL，然后发给数据库操作访问。其它不管。
   遇到的一个问题是国产数据库会卡死。一段时间开启连接以后就卡住了。服务端停止工作。就想在数据库操作那里设置超时或者检查被卡住的线程。太多就重启。这样不会影响实时业务，只影响统计业务。

Answer 11

微软其实本身就有里要的东西微软把他叫“restfull odata”这个其实已经集成在vs里了，不过实际上用处不大。他是给原来喜欢玩数据库直连的程序员使用的
这波程序员以前是数据直连，后来搞个wcf间接操作数据库（他的wcf传递的也都是数据库表），当然构造wcf他们觉着麻烦，微软就给了个odata让你直接把数据库变成wcf或者restfull操作不过就像楼上说的，现在其实不提倡这种把表操作当做设计的方式。现在是微服务，强调的是业务服务，而非curd

Answer 12

你这就是民科的想法了，你真要将web mvc和服务分离，那用微服务好了，不用自己规划什么架构。你要趟的所有坑，微服务都给你解决了，何必自己再趟一遍。