系统接口设计规范（接口详细设计）

网友投稿 1337 2022-12-29

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

本文目录一览：

1、接口设计评审规范
2、多终端为什么采用restful的接口设计规范
3、java为什么要设计接口规范
4、求操作系统接口：Windows命令接口设计（C++编的）谢谢
5、数据接口

接口设计评审规范

本接口设计规范，参考了restfull的部分设计理念。

资源是 Restful API 的核心元素，所有的操作都是针对特定资源进行的。

任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：

Github 可以说是这方面的典范，下面我们就拿 repository 来说明。

我们可以看到几个特性：

接口名称应简单明了，望文知意，接口简介中，需描述清楚接口的具体业务功能。

原则上，接口命名规范整体采用“名词”+“动词”形式

接口返回或者操作的是单个资源对象，采用名称的单数形式命名，如：/user/add，/user/del，/user/get

接口返回或者操作的是多个资源对象，采用名称的复数形式命名，如：/users/get

针对同一个接口，根据实际业务需求，为解决接口兼容性问题，可以对接口进行版本扩展，命名规范为“名词”+“动词”+“版本号”形式，版本号采用v1、v2、v3形式命名

例：/user/login ，/user/login/v1

接口返回值，将统一采用如下格式：

{
"sign": "f64b967289ac4d8cbfdc22ad30ec9d09",
"content": "{}",
"timestamp": 1561204602005,
"desc": "成功!",
"code": "000",
"accessToken": "83BAED4DAE9DEF783FDE243F4B5C"
}

sign:返回值签名验签（如果需要）

如遇第三方合作等特殊情况，根据实际情况进行设计。

一个接口只做一件事情

连字符"-"一般用来分割URI中出现的字符串(单词)，来提高URI的可读性，使用下划线"_"来分割字符串(单词)可能会和链接的样式冲突重叠，而影响阅读性。

根据RFC3986定义，URI是对大小写敏感的，所以为了避免歧义，我们尽量用小写字符。

例，针对金额，都统一为amount，而不是有的amount，有的money。

如是对老接口进行改动，需考虑接口的兼容性，包括字段的增减、字段名称调整、字段类型的调整、字段值内容长度的调整，字段值取值范围的调整等。

接口一旦发布就不易修改，要保持兼容性，拼写错误也不能改了，所以要仔细检查拼写。
著名悲剧：unix 的 creat。

creat是一个函数，可以用来创建一个文件并以只写的方式打开。

参数命名最好是定语+名词
比如 fileName, maxSize, textColor，而不是用name、size、colour

不要用生僻单词，也不要用汉语拼音

除非是约定俗成已经被广泛使用的缩写，否则老老实实用完整拼写。

比如有open就要有close，有login就要有logout，这些单词基本是固定搭配的，使用者就很容易理解。

例，业务需要vip用户，接口不允许设计为isVipUser，而应该设计为获取用户的会员等级接口，/user/level/get，这样保证接口的通用性和扩展性

分页相关接口参数命名统一：

pageSize:每页记录条数

pageNum:当前页数

totalPageNum:总共页数

统一以分为单位进行传递

建议统一以时间毫秒数进行传递，避免前后端或者各种场景下日期格式不统一

系统接口设计规范（接口详细设计）

多终端为什么采用restful的接口设计规范

REST（REpresentationStateTransfer）描述了一个架构样式的网络系统，比如web应用程序。
它首次出现在2000年RoyFielding的博士论文中，他是HTTP规范的主要编写者之一。
REST指的是一组架构约束条件和原则。
满足这些约束条件和原则的应用程序或设计就是RESTful。
Web应用程序最重要的REST原则是，客户端和服务器之间的交互在请求之间是无状态的。
从客户端到服务器的每个请求都必须包含理解请求所必需的信息。
如果服务器在请求之间的任何时间点重启，客户端不会得到通知。
此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。
客户端可以缓存数据以改进性能。
在服务器端，应用程序状态和功能可以分为各种资源。
资源是一个有趣的概念实体，它向客户端公开。
资源的例子有：应用程序对象、数据库记录、算法等等。
每个资源都使用URI（UniversalResourceIdentifier）得到一个惟一的地址。
所有资源都共享统一的界面，以便在客户端和服务器之间传输状态。
使用的是标准的HTTP方法，比如GET、PUT、POST和DELETE。
Hypermedia是应用程序状态的引擎，资源表示通过超链接互联。
另一个重要的REST原则是分层系统，这表示组件无法了解它与之交互的中间层以外的组件。
通过将系统知识限制在单个层，可以限制整个系统的复杂性，促进了底层的独立性。
当REST架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。
它还降低了客户端和服务器之间的交互延迟。
统一界面简化了整个系统架构，改进了子系统之间交互的可见性。
REST简化了客户端和服务器的实现。
RESTful的实现：RESTfulWeb服务与RPC样式的Web服务了解了什么是什么是REST，再看看RESTful的实现。
最近，使用RPC样式架构构建的基于SOAP的Web服务成为实现SOA最常用的方法。
RPC样式的Web服务客户端将一个装满数据的信封（包括方法和参数信息）通过HTTP发送到服务器。

java为什么要设计接口规范

抽象类和接口
什么是接口系统接口设计规范：接口就是一些方法特征的集合------接口是对抽象的抽象。
什么是抽象类：抽象类对某具体类型的部分实现------抽象类是对具体的抽象。
方法特征包括：方法的名字、参数的数目、参数的类型。不包括：返回类型、参数名字、和抛出的异常。
接口是类型转换的前提、是动态调用的保证。实现某一接口就完成了类型的转换（多重继承）；动态调用只关心类型系统接口设计规范，不关心具体类。
       --------------------------------------------------------------------------------------------------------------------------------------
       JAVA接口（抽象类）用来声明一个新的类型。
JAVA设计师应当主要使用接口和抽象类将软件单位与内部和外部耦合起来。
换言之系统接口设计规范，应当使用JAVA接口和抽象类而不是具体类进行变量的类型声明、参数的类型声明、方法的返回类型声明、以及数据类型的转换等。
当然一个更好的做法是仅仅使用接口，而不是抽象类来做上面这些事情。
在理想的情况下，一个具体类应当只实现接口和抽象类中声明的方法，而不应当给出多余的方法！
接口和抽象类一般作为一个类型等级结构的起点。
接口比抽象类更为抽象所以优先使用接口声明抽象类型！
--------------------------------------------------------------------------------------------------------------------------------------
抽象类和接口
       抽象类仅提供一个类的部分实现。抽象类可以有实例变量、以及一个或多个构造函数。抽象类可以同时又抽象方法和具体方法。
       一个抽象类不会有实例，它的构造函数不能被客户端用来创建实例。一个抽象类的构造函数可以被其子类调用，从而使一个抽象类的所有子类可以有一些共同的实现，而不同的子类可以在此基础上有不同的实现。
接口比抽象类更为抽象所以有线使用接口声明抽象类！
抽象类是用来继承的。（具体类不是用来继承的，“只要有可能不要从具体类继承---SCOTT MERYES”）。
抽象类设计原则：
1.          抽象类应当拥有尽可能多的代码！（公用方法）。代码集中于抽象的方向。
2.          抽象类应当拥有尽可能少的数据！（公共属性）。数据集中于具体的方向。
继承复用的使用条件------- PETER COAD条件
1.        子类是超类的一个特殊种类而不是超类的一个角色！正确区分“HAS-A”“IS-A”的关系。
2.        子类之间不应发生替换！系统接口设计规范？
3.        子类具有扩展超类的责任，而不是置换（OVERRIDE）掉或注销（NULLIFY）掉的责任。
4.        只有在分类学角度上有意义时才可以使用继承，不要从具体类继承。
接口和抽象类的区别：
    1.       抽象类可以提供某些方法的实现。如果向抽象类中加入一个新的具体的方法，那么所有的子类一下子就得到了这个方法。接口做不到这一点！（这也许是抽象类的唯一优点）。
2.      因JAVA的单根结构限制，只类只能实现一个抽象类类型，而接口类型这无此限制。这使抽象类作为类型定义工具的效能落后于接口。接口是定义混合类型（实现多从继承）的理想工具：用一个
3.      从代码重构的角度上讲，将一个具体类重构成一个接口的实现是很容易的。

文章来自 haoyu1566的网易博客

求操作系统接口：Windows命令接口设计（C++编的）谢谢

基于XML的配置文件访问接口设计和实现(1)
目录
摘要
配置文件结构
XmlConfigReader类的实现
XmlConfigReader类的使用
摘要
在进行程序开发过程中,经常要将一些程序设置/使用的信息储存起来.由于这些信息和程序的设置/使用相关,与程序有相当的独立性,所以不可能硬编码到程序中.在这个时候我们选择使用基于Xml的配置文件进行存储.Microsoft的.NET Framework提供了一系列的基于.Config文件的读取的类,如System.Configuration 命名空间提供的AppSettings等类.但是此命名空间提供的类只能对配置文件进行读取,不能进行设置.所以在这里,我们实现自己的一个基于Xml的配置文件的类XmlConfigReader/XmlConfigWriter.
配置文件的结构
为了达到与原有的,系统自带的(.Config)配置文件的兼容性,我们选择使用类似.Config 文件的结构.示例如下:
<?xml version="1.0" encoding="utf-8" ?
<configuration
<appSettings
<add key="TimeOut" value="5000"/
<add key="UserName" value="client7" /
<add key="FileServerPort" value="8050" /
<add key="SpliteCharsForCMD" value=":"/
<add key="SpliteCharsForItem" value=";"/
<add key="SpliteCharsForSubItem" value=","/
</appSettings
<SockBaseSettings
<addd key="ServerIP" value="localhost"/
</SockBaseSettings
</configuration
所有的要设置的信息都放在Configuration节点的子节点(如appSettings/SockBaseSettings)的子节点中,这种结构有助于将不同的设置的信息进行归类/统一.结构和系统的.Config结构基本类似.这样就可以很方便的将此自定义的结构转为.Config文件.
XmlConfigReader类的实现
现在文件的基本结构已完成了,现在就开始编码,完成XmlConfigReader.
由于配置文件是以文件的形式放在硬盘上面的,所以这个XmlConfigReader类在解析Xml文件前得得到文件的路径.
public class XmlConfigReader
{
private string _filepath;
public XmlConfigReader(string filepath){
_filepath = Path.GetFullPath(filepath).ToUpper();
}
}
好,现在可以得到文件路径了.然后就是对配置文件进行解析了.在这里,我们选用.NET Framework提供的System.Xml命名空间中的轻量级的XmlTextReader来对配置文件进行解析.对应的XmlConfigReader中的函数定义如下:
public string Process(string sectionName,string key){
bool inConfiguration = false;
bool inSection = false;
string values;
XmlTextReader reader = new XmlTextReader(_filepath);
while( reader.Read()){
if( reader.IsStartElement()){
if( reader.Prefix == String.Empty)
{
if( reader.LocalName == "configuration")
{
inConfiguration = true;
}
else if( inConfiguration == true){
if( reader.LocalName == sectionName){
inSection = true;
}
else if( inSection reader.LocalName == "add"){
if( reader.GetAttribute("key") == null || reader.GetAttribute("value") == null)
{
throw new Exception(sectionName + " key or value is null");
}
if( reader.GetAttribute("key") == key){
values = reader.GetAttribute("value");
break;
}
}
}
}
}
}
reader.Close();
return values;
}
通过XmlTextReader的Read()函数对Xml文件中的节点进行遍历.同时先判断是否属于configuration节点中,再判断是否属于相应的sectionName中.只有在这两部分同时成立的时候才判断是否是相应的Key.如果是,得到其Value,并返回.
XmlConfigReader类的使用
好了,现在通过XmlConfigReader可以对配置文件进行读取了,这里我们看看实际使用的代码:
public class TestXmlConfigReader{
public void GetValues(){
XmlConfigReader reader = new XmlConfigReader(@"AppConfig.xml");
String Temp;
// Get appSettings username value
Temp = reader.Process("appSettings",”UserName");
// Get SockBaseSettings ServerIP value
Temp = Reader.Process(“SockBaseSettings”,”ServerIP”);
}
}
总结
通过XmlConfigReader类,我们可以很方便的自定义我们自己的配置文件.
基于XML的配置文件访问接口设计和实现(2)
目录
摘要
XmlConfigWriter类的实现
XmlConfigWriter类的使用
摘要
在进行程序开发过程中,经常要将一些程序设置/使用的信息储存起来.由于这些信息和程序的设置/使用相关,与程序有相当的独立性,所以不可能硬编码到程序中.在这个时候我们选择使用基于Xml的配置文件进行存储.Microsoft的.NET Framework提供了一系列的基于.Config文件的读取的类,如System.Configuration 命名空间提供的AppSettings等类.但是此命名空间提供的类只能对配置文件进行读取,不能进行设置.所以在这里,我们实现自己的一个基于Xml的配置文件的类XmlConfigReader/XmlConfigWriter.
XmlConfigWriter类的实现
由于要对配置文件进行写入,而且可能写入的次数比较多.所以这里我们不使用轻便的XmlTextWriter,使用XmlDocument.XmlDocument可以在内存中修改所有的Xml的节点,只有等到显式的调用Save函数的时候才会保存Xml文件.在有大量修改的时候,性能要好一些.
同样的,先实现XmlConfigWriter的构造函数
public class XmlConfigWriter
{
private string _filepath;
private XmlDocument doc ;
public XmlConfigWriter(string filepath)
{
_filepath = Path.GetFullPath(filepath);
doc =new XmlDocument();
doc.Load(_filepath);
}
}
通过构造函数,将配置文件的路径传进去,同时调用XmlDocument的Load方法,将此文件加载到内存中.
这里我们使用的是XmlDocument类.它实现 W3C 文档对象模型 (DOM) 级别 1 核心 (Level 1 Core) 和核心 DOM 级别 2 (Core DOM Level 2)。DOM 是 XML 文档的内存中（缓存）树状表示形式，允许对该文档的导航和编辑.通过XmlDocument,我们就可以很方便的在内存中直接操作节点.
.对配置文件的写入,不外忽三种,一种就是新插入一个节点,一种就是对现有节点的修改,最后一个就是删除现有的节点.我们首先从插入开始入手.代码如下:
private XmlNode CreateXmlNode(string localname){
return doc.CreateNode(XmlNodeType.Element,localname,"");
}
private XmlAttribute CreateXmlAttribute(string localname){
return doc.CreateAttribute("",localname,"");
}
public void AddSection(string section){
XmlNode secNode = doc.SelectSingleNode("/configuration/"+section);
if(secNode != null){
return;
}
doc.DocumentElement.AppendChild(CreateNode(section));
}
public void AddKey(string section,string key,string value){
XmlNode secNode = doc.SelectSingleNode("/configuration/"+section);
if( doc.SelectSingleNode("/configuration/" + section + "/add[@key=\"" + key + "\"]") != null)
{
return;
}
XmlNode chi = CreateXmlNode("add");
XmlAttribute att = CreateXmlAttribute("key");
att.Value = key;
chi.Attributes.Append(att);
att = CreateXmlAttribute("value");
att.Value = value;
chi.Attributes.Append(att);
secNode.AppendChild(chi);
}
对于配置文件的插入,有两种情况,一个就是插入一个新的Section节点(即appSettings/SockBaseSettings这样的节点),一个就是在当前的Section节点下面插入一个新的add节点.在上面的代码中,对于插入节点的操作,都是首先通过doc的SelectSingleNode函数来判断是否已存在此同名节点,如果存在,则直接return,避免创建同名的节点.但是,由于在最终使用的add节点是分属于不同的Section节点的,所以只是判断在同一个Section节点下面的此节点不能同名.
如果不存在同名的节点,就通过secNode.AppentChild函数将此新建的(通过CreateXmlNode函数)节点加入到doc对象中.同时,对于add节点,通过CreateXmlAttribute函数及XmNode.Attributes.Appent函数将其key / value属性加入到此节点中.这样,插入操作就完成了.
接着我们来完成删除操作.删除操作直接通过XmlDocument的SelectSingleNode得到目标节点的父节点,再通过XmlNode.RemoveChild操作将其删除.代码如下:
public void DeleteSection(string section){
XmlNode secNode = doc.SelectSingleNode("/configuration/"+section);
doc.DocumentElement.RemoveChild(secNode);
}
public void DeleteKey(string section,string key){
XmlNode secNode = doc.SelectSingleNode("/configuration/" + section + "/add[@key=\"" + key + "\"]");
if(secNode != null)
{
secNode.ParentNode.RemoveChild(secNode);
}
}
现在开始修改操作.对于修改操作,思路是这样的,首先通过XmlDocument的SelectSingleNode搜索,看是否有满足条件的节点.如果没有,直接return,如果存在,则分两情况.对于add节点,只是直接修改其value属性.对于Section节点,则是通过遍历把其下所有的子节点(add节点)得到,再把此Section节点删除,再生成一个新的节点(这个新的节点的Name就为要设置的值),再把得到的所有子节点再赋给这个新的节点.代码如下:
public void ModifySection(string oldSection,string newSection){
XmlNode secNode = doc.SelectSingleNode("/configuration/"+oldSection);
XmlNodeList list = secNode.ChildNodes;
doc.DocumentElement.RemoveChild(secNode);
secNode = doc.CreateNode(XmlNodeType.Element,newSection,"");
foreach( XmlNode i in list){
secNode.AppendChild(i);
}
doc.DocumentElement.AppendChild(secNode);
}
public void ModifyKey(string section,string key,string value){
XmlNode secNode = doc.SelectSingleNode("/configuration/" + section + "/add[@key=\"" + key + "\"]");
if(secNode != null)
{
secNode.Attributes["value"].Value = value;
}
}
好了,插入,修改,删除操作到现在基本完成了,但是现在还只是在内存中进行操作,还不是对实际的文件进行操作.这个时候,我们就还得通过XmlDocument.Save函数把内存中修改好的Xml文件写入到文件中去.代码如下:
public void Save(){
doc.Save(_filepath);
}
public void Save(string filepath)
{
doc.Save(filepath);
}
XmlConfigWriter类的使用
使用方法很简单.先产生一个XmlConfigWriter对象,通过构造函数把配置文件传进去,再通过Add/Modify/Delete等函数进行操作.代码如下:
XmlConfigWriter Writer = new XmlConfigWriter(@”appconfig.xml”);
Writer.AddSection(“appSettings”);
Writer.AddKey(“appSettings”,”ServerIP”,”localhost”);
Writer.ModifyKey(“appSettings”,”ServerIP”,”127.0.0.1”);
Writer.ModifySection(“appSettings”,”SockBaseSettings”);
Writer.DeleteKey(“SockBaseSettings”,”ServerIP”);
Writer.DeleteSection(“SockBaseSettings”);
Writer.Save();
总结
通过编写XmlConfigWriter,我们学会使用XmlDocument的使用.
基于XML的配置文件访问接口设计和实现(3)
目录
摘要
增加缓存支持
增加配置文件监视
增加ConfigurationSettings类
摘要
前面的两篇中,我们实现了XmlConfigReader和XmlConfigWriter的基本功能.由于XmlConfigReader的实现方式是每请求一次,就去解析配置文件一次,性能很低下.同时,为了更方便使用,我们增加一个ConfigurationSettings类,用来调用XmlConfigReader和XmlConfigWriter,使之用起来和System.Configuration中的类使用方式一样.
增加缓存支持
由于XmlConfigReader的实现方式是请求一次,解析配置文件一次,而且配置文件的信息在程序运行的时会大量使用,这样子显然效率太低.因此,这里就要使用到缓存.
缓存,其实就相当于一个静态的变量,在整个程序运行时是唯一的,通过这样的一个变量,把信息存储到这个变量里面,在程序的其它地方就可以直接得到这个信息了.从而避免了频繁的解析配置文件.这里,我们选择使用Hashtable做为缓存变量.
在MSDN中,我们可以查到System.Configuration命名空间中的AppSettings类返回的是一个NameValueCollection(Key/Value键值对).为了方便使用,我们将配置文件解析后的信息也存成NameValueCollection这样的集合.
这样定义好了后,对于Hashtable中的Key设置为Section节点的名字(appSettings/SockBaseSettings),其Value值即为此节点的所有子节点的NameValueCollection类的对象.
修改代码.给XmlConfigReader增加一个静态Hashtable变量,并修改相关函数.把得到的信息直接以NameValueCollection的形式存入到此Hashtable中.
private static Hashtable confTypes = new Hashtable();
private string rootname;
public void Process(){
XmlTextReader reader = new XmlTextReader(_filepath);
while( reader.Read()){
if( reader.IsStartElement()){
#region Analyze the files
if( reader.Prefix == String.Empty)
{
if( reader.LocalName == "configuration")
{
inConfiguration = true;
}
else if( inConfiguration == true){
if(reader.LocalName == "add")
{
if( reader.GetAttribute("key") == null || reader.GetAttribute("value") == null)
{
throw new Exception(rootname + " key or value is null");
}
AddKey(tables,reader.GetAttribute("key"),reader.GetAttribute("value"));
}
else
{
rootname = reader.LocalName;
}
}
}
#endregion
}
else if ( reader.LocalName == "configuration"){
inConfiguration = false;
}
}
reader.Close();
}
private void AddKey(string key,string value){
NameValueCollection collection ;
if(confTypes.ContainsKey( rootname )){
collection = (NameValueCollection) confTypes [rootname];
}
else{
lock(confTypes.SyncRoot){
collection = new NameValueCollection();
confTypes.Add( rootname,collection);
}
}
collection.Add(key,value);
}
上面代码中,我们修改了Process函数.把原来的直接return结果的地方改成调用AddKey函数.通过一个类成员 rootname临时储存当前的SectionName,通过AddKey把得到的Key/Value加入到Hashtable中.
现在这样修改后,就不能直接通过Process得到我们想到得到的Key的Value了.所以我们再写一个函数,
public NameValueCollection GetCollection(string SectionName){
if( confTypes.ContainsKey(SectionName)){
return (NameValueCollection)confTypes[SectionName];
}
else{
throw new Exception(confName + " is not found in XmlConfiguration files");
}
}
这里,我们直接通过SectionName得到此节点所有的子节点的NameValueCollection集合.这样,我们就可以得到我们想要的值了.
增加配置文件监视
上面的代码实现了配置文件的缓存.大大提高了灵活性.但是存在一个问题,就是,如果配置文件修改了,这个缓存不会自动更新.
要解决这个问题,我们得使用FileSystemWatcher这个类,用来订阅文件修改消息,进而更新缓存.由于在第一次解析前就要把此配置文件加入到监视文件表中,所以我们修改XmlConfigReader,增加一个静态的FileSystemWatcher,用来保存监视文件的对象,增加一个静态的Bool值表明是否修改过.再修改构造函数,使配置文件在一开始就加入到监视列表中.代码如下:
Private static FileSystemWatcher watch = new FileSystemWatcher();
Private static bool isModify = true;
public XmlConfigReader(string filepath){
_filepath = Path.GetFullPath(filepath).ToUpper();
watch.IncludeSubdirectories = false;
watch.Path = Path.GetDirectoryName(filepath);
watch.NotifyFilter = NotifyFilters.Size | NotifyFilters.LastWrite;
watch.Filter = Path.GetFileName(filepath);
watch.Changed += new FileSystemEventHandler(Change_Even);
watch.EnableRaisingEvents = true;
}
由于是通过事件机制实现文件修改通知的,所以我们还要实现Chane_Even这个函数,通过这个函数修改isModify的值.
private void Change_Even(object sender, FileSystemEventArgs e){
isModify = true;
}
这样子,对于配置文件的监视的代码就完成了,现在就是修改我们的GetCollection代码的时候了.
修改后的代码如下:
public NameValueCollection GetCollection(string SectionName){
if( isModify ){
lock(confTypes.SyncRoot){
confTypes.Clear();
Process();
}
isModify = false;
}
if( confTypes.ContainsKey(SectionName)){
return (NameValueCollection)confTypes[SectionName];
}
else{
throw new Exception(confName + " is not found in XmlConfiguration files");
}
}
到现在,整个XmlConfigReader的代码已完成了,可以实现对文件的监视,从而动态修改缓存中的值.
增加ConfigurationSettings类
为了便于使用,我们增加了一个ConfigurationSettings的类,使用他的用法和System.Configuration命名空间中的类的用法一样.代码定义如下:
public class ConfigurationSettings : XmlConfigWriter
{
private static string _filepath = @"AppConfig.xml";
public static string DefaultFilePath
private static XmlConfigReader reader;
{
get{return _filepath;}
set{_filepath = Path.GetFullPath(value);}
}
public static NameValueCollection AppSettings
{
get{
if( reader == null){
reader = new XmlConfigReader(DefaultFilePath);
}
return reader.GetCollection("appSettings");
}
}
public static NameValueCollection GetConfig(string sectionName){
get{
if( reader == null){
reader = new XmlConfigReader(DefaultFilePath);
}
return reader.GetCollection(sectionName);
}
}

数据接口

系统在运行中将用到大量的数据资料，必须在设计初始就明确各类数据标准以及各子系统的数据接口。根据各子系统设计的数据项需求及产生的成果数据项，确定各项数据的数据表，定义表结构，进行代码设计，然后由数据库系统实施，同时形成文档，作为系统的数据标准，统一执行。

数据的分类、编码设计、数据库的设计、地图制图、数据录入和质量检验，均遵循国家和行业主管部门的标准、规范、规程;如没有统一的规范规程，则参照相关的规程进行规范化设计。系统有关的数据定义全部形成文档，作为技术规范，统一使用。

各子系统在设计时应当明确与相关子系统的数据关系，提出相关子系统必须提交的数据表要求和系统运行过程中的提交时间，对应子系统按照该提交数据要求在系统中进行相应设计和开发，保证数据流动的通畅，这是基于数据的系统集成方案的关键，是数据平台接口设计的重要依据。系统间数据关系须形成文档，作为系统间数据接口标准规范，统一执行。

数据关系与数据标准相辅相成，共同定义了数据平台与各个子系统之间的输入、输出接口。在数据接口设计中应重点考虑以下几个方面:

(1)遥感数据与图形数据的接口:利用图形配准技术，予以解决。遥感数据是动态监测专题图件产生的基础，必须经过坐标配准，才能产生专题图件。配准过程由遥感动态监测子系统执行，需要应用综合数据库中的地形图数据。在配准后遥感数据与图形数据的套合依据空间坐标进行。

(2)空间数据与属性数据的接口:利用关键字建立联系。在数据建库过程中依据数据标准有关文档规定建立图形库和属性库结构，确定关键字段，同时定义关键字段编码方案，保证关键字段唯一性。在数据采集过程中对关键字段赋予代码。系统维护过程中的数据采集也必须依据编码方案对关键字段赋值。在应用系统中使用时只需建立图形库与属性库间的关联即可。

( 3) 子系统之间数据的接口: 各子系统之间数据的交换通过数据库进行，所以子系统间数据接口本质上是子系统与后台数据库的接口; 在建立数据库时，已经由数据库管理系统依据系统间数据关系建立了接口。

系统内数据关系包括:

数据管理与数据库子系统接受业务处理与信息服务子系统录入的有关基础信息、遥感动态监测子系统输入的遥感数据及各子系统产生的成果数据，为各子系统提供综合基础数据、专题数据和成果数据。

遥感动态监测子系统需要数据库系统管理的遥感数据、地形图数据和历史专题数据。

生态专业分析子系统需要遥感动态监测子系统产生的专题图件和综合数据库中的历史专题图件以及属性资料。

业务处理与信息服务子系统需要数据库子系统管理的综合基础数据和各专业应用子系统产生的成果数据。

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

标签：接口设计实现接口接口设计规范数据接口设计接口详细设计

暂时没有评论，来抢沙发吧~

系统接口设计规范（接口详细设计）

接口设计评审规范

多终端为什么采用restful的接口设计规范

java为什么要设计接口规范

求操作系统接口：Windows命令接口设计（C++编的）谢谢

数据接口

为什么枚举要实现接口？

接口测试的核心概念是什么

java接口与抽象类有哪些区别？

推荐文章

接口调用是什么意思？几种常用接口调用方式

接口设计原则

8款在线 API 接口文档管理工具

api管理系统是什么？

什么是接口调试？接口调试的步骤有哪些？

api 接口管理系统有哪些？

接口测试有几种测试方法

API文档生成工具有哪些？

微服务和api网关区别

交换机配置步骤

最近发表

热评文章

在线接口文档管理工具推荐，支持在线测试，HTTP接口

开源的在线接口文档wiki工具Mindoc的介绍与使

如何优雅的进行接口设计？接口设计的六大原则是什么？

什么是API测试,api检测公司

软件接口设计怎么做？前后端分离软件接口设计思路

接口管理平台推荐，几大接口管理平台总有一款适合你！

系统接口设计规范（接口详细设计）

接口设计评审规范

多终端 为什么采用restful的接口设计规范

java为什么要设计接口规范

求操作系统接口：Windows命令接口 设计（C++编的） 谢谢

数据接口

推荐文章

最近发表

热评文章

多终端为什么采用restful的接口设计规范

求操作系统接口：Windows命令接口设计（C++编的）谢谢