整合 接口设计（整合 接口设计图）

本篇文章给大家谈谈整合 接口设计，以及整合 接口设计图对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享整合 接口设计的知识，其中也会对整合 接口设计图进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、App 和 Web 的通用接口该怎么设计
• 2、Hibernate和spring整合后为什么要用DAO接口
• 3、定制服务器都是怎么设计出来的啊？
• 4、请问那位大虾知道数据库接口是怎么整合的
• 5、当前最为普及和流行的标准接口USB TYPE-A为何不能正反插？

App 和 Web 的通用接口该怎么设计

1、在接口定义中确定MVC的GET或者POST方式
由于我们整个Web API平台是基于MVC的基础上进行的API开发整合 接口设计，因此整个Web API的接口整合 接口设计，在定义的时候，一般需要显示来声明接口是[HttpGet]或者[HttpPost]，虽然有些接口也可以不用声明，但是避免出现类似下面的错误信息，显式声明还是有好处的。
请求的资源不支持 http 方法“POST
例如在基类定义的查找对象接口如下所示。
/// <summary
/// 查询数据库,检查是否存在指定ID的对象
/// </summary
/// <param name="id"对象的ID值</param
/// <returns存在则返回指定的对象,否则返回Null</returns
[HttpGet]
public virtual T FindByID(string id, string token)
如果是增删改的接口，一般需要声明为POST方式提交数据，而且基于安全性的考虑，需要携带更多的参数。
/// <summary
/// 插入指定对象到数据库中
/// </summary
/// <param name="info"指定的对象</param
/// <returns执行操作是否成功。</returns
[HttpPost]
public virtual CommonResult Insert(T info, string token, string signature, string timestamp, string nonce, string appid)
2、动态对象的接口定义
在一般的Web API接口里面，我们可能都会碰到很多简单类型的参数，但是又想让它们以POST方式提交数据，那么我们就可以有两种方法来处理，一种是定义一个类来放置这些参数，一种是采用动态的JObject参数，前者有很多不方便的地方，因为我们不可能为每个接口参数定义多一个实体类，这样可能会有很多难以管理的类定义。如下面是微信API的调用接口案例，我们也需要设置这样的处理规则。
接口调用请求说明
http请求方式: POST（请使用https协议）
https://api.weixin.qq.com/cgi-bin/groups/update?access_token=ACCESS_TOKEN
POST数据格式整合 接口设计：json
POST数据例子：{"group":{"id":108,"name":"test2_modify2"}}
那么我们采用JObject是这么样的呢，我们来看接口的定义和处理代码。JObject是Newtonsoft.Json.Linq命名空间下的一个对象。
/// <summary
/// 修改用户密码
/// </summary
/// <param name="param"包含userName和userPassword的复合对象</param
/// <param name="token"用户访问令牌</param
/// <returns</returns
[HttpPost]
public CommonResult ModifyPassword(JObject param, string token)
{
//令牌检查,不通过则抛出异常
CheckResult checkResult = CheckToken(token);
dynamic obj = param;
if (obj != null)
{
string userName = obj.userName;
string userPassword = obj.userPassword;
bool success = BLLFactory<User.Instance.ModifyPassword(userName, userPassword);
return new CommonResult(success);
}
else
{
throw new MyApiException("传递参数出现错误");
}
}
其中我们把JObject对象转换为我们所需要的对象的时候，因为我们没有定义具体的实体类，因此采用整合 接口设计了dynamic语法，声明这是一个动态对象，由运行时获取对应的属性。
dynamic obj = param;
这样我们就可以在调用的时候，动态POST对应的JSON对象给Web API接口，而不需要预先定义各种接口参数的类了。
/// <summary
/// 调用Web API接口，修改用户密码
/// </summary
/// <param name="userName"用户名称</param
/// <param name="userPassword"修改的密码</param
/// <returns如果修改成功返回true，否则返回false</returns
public bool ModifyPassword(string userName, string userPassword)
{
var action = "ModifyPassword";
var postData = new
{
userName = userName,
userPassword = userPassword
}.ToJson();
string url = GetTokenUrl(action);
CommonResult result = JsonHelper<CommonResult.ConvertJson(url, postData);
return (result != null) ? result.Success : false;
}
其中GetTokenUrl是根据token和API的地址等参数，构建一个完整的提交地址。我们在上面代码通过
var postData = new
{
userName = userName,
userPassword = userPassword
}.ToJson();
就可以动态创建一个对象，并生成它的JSON字符串，把数据POST提交到对应的API接口里面即可，然后对结果进行对象的转换就算完成了。
3、集合和分页的处理
在很多接口里面，我们都需要用到分页的处理，Web API也不例外，这样可以提交数据检索效率，减少服务器数据处理的压力，同时也提交客户端的数据显示速度。
一般的集合接口定义如下所示（通用性基类接口）。
/// <summary
/// 返回数据库所有的对象集合
/// </summary
/// <returns指定对象的集合</returns
[HttpGet]
public virtual List<T GetAll(string token)
{
//检查用户是否有权限，否则抛出MyDenyAccessException异常
base.CheckAuthorized(AuthorizeKey.ListKey, token);
List<T list = baseBLL.GetAll();
return list;
}
但是这样的返回记录会比较多，一般情况下需要分页，那么分页的处理接口定义如下所示。
/// <summary
/// 根据条件查询数据库,并返回对象集合(用于分页数据显示)
/// </summary
/// <returns指定对象的集合</returns
[HttpPost]
public virtual PagedList<T FindWithPager(string condition, PagerInfo pagerInfo, string token)
分页接口，在这里返回的结果里面，用了一个PageList的泛型类，这个方便我们获取当前的记录及总数，它的定义如下所示。
/// <summary
/// 分页集合
/// </summary
/// <typeparam name="T"对象</typeparam
public class PagedList<T
{
/// <summary
/// 返回记录的总数
/// </summary
public int total_count { get; set; }
/// <summary
/// 列表集合
/// </summary
public List<T list { get; set; }
}
最后整个分页的处理Web API接口实现如下所示。
/// <summary
/// 根据条件查询数据库,并返回对象集合(用于分页数据显示)
/// </summary
/// <returns指定对象的集合</returns
[HttpPost]
public virtual PagedList<T FindWithPager(string condition, PagerInfo pagerInfo, string token)
{
//检查用户是否有权限，否则抛出MyDenyAccessException异常
base.CheckAuthorized(AuthorizeKey.ListKey, token);
List<T list = baseBLL.FindWithPager(condition, pagerInfo);
//构造成Json的格式传递
var result = new PagedList<T() { total_count = pagerInfo.RecordCount, list = list };
return result;
}
最后客户端调用分页的Web API代码如下所示。
/// <summary
/// 根据条件查询数据库,并返回对象集合(用于分页数据显示)
/// </summary
/// <param name="condition"查询的条件</param
/// <param name="pagerInfo"分页实体</param
/// <returns指定对象的集合</returns
public virtual List<T FindWithPager(string condition, ref PagerInfo pagerInfo)
{
var action = "FindWithPager";
string url = GetTokenUrl(action) + string.Format("condition={0}", condition);
var postData = pagerInfo.ToJson();
List<T result = new List<T();
PagedList<T list = JsonHelper<PagedList<T.ConvertJson(url, postData);
if (list != null)
{
pagerInfo.RecordCount = list.total_count;//修改总记录数
result = list.list;
}
return result;
}
4、混合框架界面整合Web API接口
在整个Web API的平台构建以及在混合框架的整合过程中，我把各个模块还是遵循相对独立的方式进行开发和整合，它们实现了从直接访问数据库、以WCF服务获取数据，以及通过WebAPI调用方式获取数据几种方式的统一，从而实现了整个混合框架的高度整合。
整个混合框架的核心是以相对独立的方式，整合各个可重用的模块，我们可以遵循一定的基础上，快速构建统一的应用平台。
搭建完毕的整个WebAPI平台，其中包括了服务端内容，以API控制器的方式，发布了对应的Web API接口。
在每个混合框架的独立模块里面，我们封装了对应的Web API客户端调用处理，从而实现了Web API的调用方式。
在Win10下，使用Web API模式运行混合框架，获得的主体界面效果如下所示。
独立模块权限管理系统界面如下所示。
系列文章如下所示：
Web API应用架构在Winform混合框架中的应用（1）
Web API应用架构在Winform混合框架中的应用（2）--自定义异常结果的处理
Web API接口设计经验总结
Web API应用架构在Winform混合框架中的应用（3）--Winfrom界面调用WebAPI的过程分解
Web API应用架构在Winform混合框架中的应用（4）--利用代码生成工具快速开发整套应用
Web API应用架构在Winform混合框架中的应用（5）--系统级别字典和公司级别字典并存的处理方式

Hibernate和spring整合后为什么要用DAO接口

第一点，公司开发在设计阶段要将任务模块化，然后分给不同整合 接口设计的人甚至小组并行开发。必须设定好各个模块的接口（当然包括Dao接口）,通过接口规范方法名和参数,不然将来集成的时候每个人写的规范不一样麻烦就大了。
举个例子 在你没有写好DAO层的代码的时候，只要别人知道你的接口，就知道要怎么与你的DAO层进行通信了。
第二点，使用接口能够隐藏实现过程，方便程序维护和升级。举个例子 就DAO层的接口吧。StudentDAO studentDAO=null整合 接口设计；然后我可以通过spring注入一个OrcStudentDao();//对Orcal数据库的CRUD操作。当我的公司再开发一个项目和这个很类似，但是要使用Mysql数据库的时候只要实现这个Dao接口，然后通过spring注入一个MqlStudentDao（）;就行了，其他所有调用到这的代码通通不用改。不然就吐血去吧。
最重要的当然是第三点了 ，前两点我想光吐血还可以--毕竟有的人血厚么，这个就是半人马酋长来了也得抓狂-----
----第三点，spirng的aop当然是spring的核心之一=》事物管理又是aop的核心功能之一=》spring的aop实际上就是特殊的拦截器=》spring的拦截器实际上有两种底层的实现方式，默认的是使用jdk的动态代理=》而jdk的动态代理要求必实现类必须实现接口。好了自己往回反着推，我直接说结果吧，在你关心的这块就是Hibernate和Spring整合的时候无法使用spring 的事务管理（这简直是灾难，因为事物有八种传播特性，事物基本上都发生在Dao层，都写在代码里零零散散无法维护不说，极容易因为失误出现事物管理问题，比如数据库连接没有关闭啦，数据没有提交到数据库啦，脏数据啦... 各种灵异的问题）。好吧我承认，前面的是吓唬你的，spring的AOP有两种底层的实现，一种是刚才说的默认情况下是使用JDK的动态代理，另一种需要强制的使用cglib的动态代理，但是要引入cglib的jar库,cglib是通过继承实现动态代理的，不需要接口，但是使用cglib是不推荐的方法，这个只是用来解决遗留问题的。
除次之外随着你学习的深入，将精力从编码转向到设计的时候，你就知道接口，抽象，封装，继承... 这些的好处了，这不是一言能尽的事。
以上是个人的理解不是标准答案

定制服务器都是怎么设计出来的啊？

一般来说，定制服务器主要是在于以下四点的设计：

1、共享组件

出于资源利用及节能需求，服务器在定制化过程中通常可以采用共享组件的方式提升空间资源的利用率，从而降低能耗，类似的做法包括将多个服务器节点置于同一机箱空间内、多个服务器共享风扇及电源组件等。例如在4U空间内集成8 台1U服务器或4 台2U服务器，并实现电源及风扇的共享使用，较传统机架服务器部署密度提升，能耗降低，同时建造成本也下降了。

2、整合接口

为了进一步提升服务器内部线路及空间资源的利用率，服务器定制化过程中可以将一些常用的接口，如对USB、VGA等进行集成整合，形成统一的标准化接口。

3、按需配置部件

不同数据中心面向的用户群体不同，这导致其承担的业务负载有所差异。比如说互联网数据中心的业务一般单一且规模较大，因此服务器可以按照单一应用来深度定制。而对于大部分运营商来说，其数据中心面临的业务则较为分散，长词需要同时处理人工智能、Web、视频等多种类型的应用服务，在这种情况下，数据中心需要面向不同应用部署相应的定制化服务器。

在服务器定制化过程中，数据中心可以根据业务对资源的需求及服务级别协议的要求对服务器CPU、内存、IO、网卡及硬盘等部件进行针对性的配置，适当减少利用率较低的硬件资源，增加业务负载需求量较大的资源，从而防止资源的过度配置，同时避免了某些资源配置不足造成资源瓶颈。

4、按需定制软硬件

在外部政策及企业内部控制制度制约下，数据中心会产生某些特定的运维管理需求，这类需求实际上形成了对服务器原有功能的拓展，部分拓展功能的实现需要定制化的软件及硬件支持。例如，不少数据中心用户希望实现对服务器的远程管理，以此进一步降低数据中心运营管理成本、提升运营效率，并且在恶劣天气、当下疫情等不良的外部环境下，服务器远程管理功能能够降低运维人员外出工作的安全风险。为了满足这种特定的功能需求，定制化服务器可以实现智能平台管理接口开放，部署相应的远程管理工具，同时根据软件功能需求对底层硬件进行定制，如基板管理控制器BMC的定制等。

参考链接：定制服务器有哪些关键技术？

请问那位大虾知道数据库接口是怎么整合的

数据库接口就是给整合 接口设计你个数据库用户拥有访问相应表的权限整合 接口设计，然后把表结构和表关系告诉整合 接口设计你整合 接口设计，你再编代码实现增删改就OK了
如果数据没有重叠，就依然各用各的就行了。
如果数据有重叠（比如两个数据库都有用户表，一个数据库的用户没有等级列，而另一个数据库用户有等级列），就费劲了。
就得重新画新数据库的表关联。
把数据有重叠的两个表结构做成一样的，用SQL语句填补空缺的数据，把其中一个数据库表的数据导入到另一个数据库中。
手工比较繁琐。

当前最为普及和流行的标准接口USB TYPE-A为何不能正反插？

　USB，准确的说是USB TYPE-A，无疑是目前最为普及和流行的标准接口。即便USB TYPE-C有取而代之的趋势，但在短时间内，在大量外接设备还无法完全过渡到TYPE-C的情况下，电脑或其它数码设备上TYPE-A型USB依旧会是最主流的接口。为何TYPE-A型USB在设计之初并未采用可正反插的方式呢？

01 原因一：设计思维

其实“从古至今”的各类标准接口，在防呆设计上都普遍采用了“不兼容的物理设计”方式。在接口设计之初，正常思维不是考虑正反插，而是考虑“反着插肯定插不进去，所以不会刻意去设计成可正反插的样式”。

比如电脑上各类标准接口，网线口、DP口、HDMI口、老一些的如VGA接口、PS2接口等等，都采用了不兼容的物理设计方式。如水晶头上的凸起、HDMI上宽下窄的异型设计、VGA的针位错列、PS2接口/DP接口的缺口设计等等，都属于不兼容式的物理防呆设计方案。

接口通常使用形状或物理防呆设计来区分正反

事实上，TYPE-A型USB也属于不兼容式的物理防呆设计方案，它利用上下不一的厚度防呆设计帮助用户判断正确的插入位置。但是，与上述那些相对更加明显的防呆设计相比，TYPE-A型USB的失败之处就在于，它的防呆设计不明显，且使用了规则的矩形设计。其最大败笔不在于只能单向插，而在于不能通过观察外表和触摸，简单而快速的区分正反之后实现盲插。

因此很多时候在插入USB线的时候，往往盲插很多次都插不进去，还是要费力再去确认一下正反向才能顺利插入。

02 原因二：技术变迁规律

除了设计思维层面的原因之外，TYPE-A型USB之所以在设计之初并未考虑正反插还有一个重要原因就是接口技术。

事实上，所有技术的发展都是具有延续性的，这也意味着技术进步或突破方面，创新要比创造更加容易一些。在技术发展的最初阶段，最先要做的是设计出一个原型，至于优化性能、结构、外观、甚至是用户体验，往往都是后续技术成熟之后才会去做的事情。现阶段最明显的例子就是智能机器人领域。

说回到USB接口。TYPE-A型USB所处的数据传输技术领域也是按照上述模式在发展。USB接口出现主要是目的是要设计一个通用的外设接口，用一个接口解决PCI这种内置的、不好插拔的接口的数据传输问题；将PS/2、串口、并口这些规格不同、五花八门的接口整合到一起，同时解决这些针式接口容易损坏的问题。

关于整合 接口设计和整合 接口设计图的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 整合 接口设计的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于整合 接口设计图、整合 接口设计的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。