即使使用接口, 不关心实现, 还是有几个问题需要考虑的,首先就是接口函数参数的数据类型问题,对于业务数据是用业务类来封装, 还是使用 DataTable 这些便捷设施如果你提供的接口实现对方不满意, 他们是否可以很方便的编写自己的实现.归根到底就是 Type 问题, ----------------- type of typeless, root of rootless
Sync Framework , 你搭Host, 人家写Client (代码都没多少行），人家也不需要知道你的接口，按照Sync Framework 进行调用你 Host WebService 即可 web service, xml 都已经封装好了，也不需要人家做什么太多的代码你只要把数据变更，或者说Sync 逻辑做好即可。
Sync Framework 都给你做好了
Web Service是目前为止异构系统通信的唯一通用标准...你不了解合作者的系统就当它是异构系统好了...你只需要抽象出“获取经过处理和分析的相关数据的方法”以Web Service实现并发布，将WSDL文档给你的合作者，他们自己知道该怎么做...在这个协作系统中你是provider，应该由你来确定你的API的细节不需要合作者参与，合作者只要给出需求即可...所以你只要问清楚你的上家都需要些什么数据，发布方式和格式你定义好告知对方就行了...
能就你提出的方案:进行再次深一层的描述吗?
恩:我会去先了解一下web services.谢谢.不知道7楼所说的实现方式,仁兄您可有见解!
编写应用程序就够JB难的了, 谁知 toolkit 更难, framework 就更别提了.发动大脑, 设计期间不设限吧.
http://zh.wikipedia.org/zh-cn/%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E6%8E%A5%E5%8F%A3
顶多告诉他们结果集的字段的意义以及接口参数的意思。
这个之前也想过了.但就我个人而言webservices知道太少.已以充电中……
我觉得你更应该关注的是：对方需要你提供什么东西，格式如何，他们会以什么样的方式调用等内容如果数据是现成的，而且允许对方直接连接数据库，那么你可以考虑使用存储过程或者视图来进行，将数据转换对方需要的格式，也方便进行授权和访问控制如果对方通过互联网访问，可以考虑webservice如果需要提供的数据在处理逻辑上比较复杂，可以考虑做成库，给对方调用
有连接的时候给他返回分析后的他要的数据 返回json/xml就好
1、直接提供数据库的表结构，这是一种接口，这种方法比较冒险。
2、可以用webService的方法提供一些方法给外部调用。
3、或则提供dll类库。
还有更多，如Windows消息等。具体看项目的需求。
我看这个需求只是数据传输上的需求。
对方的需求是假设仅是你处理完的数据（表、条目、记录。
而不是用你接口提供的方法、服务（业务处理）。你可以用一个完善的数据传输框架实现。也是webservice, 只有区区几个框架接口。Microsoft Sync Framework 就可以实现这个需求。 对方只要访问这个Sync Service 来请求数据就可以了。 你在Sync Framework 下写上他能请求的逻辑规则。 什么数据他可以请求
第二套API也可看是否需要。
第三套直接公布数据库视图的方案本人在分析中。同时也说明一下上家所要的数据.
基实上家只是要我软件生成的报警数据，数据量不会过大，每次可能会提取100-600行放有20多列的数据，现在还不确定多长时间提取一次，可以肯定的是每天至少进行4到12次提取。
还有就是数据结构这方面，我之前认为数据结构在给上家前在我的软件 里进行结构重组再提交，因为上家需要的数据还自多张表，而这多张物理表里有很多上家不需要的(当然通过数据过视图也可以实现安全及共享)。可方案实现时需求注意什么.
定义数据类型到 xml schema 的关系(xml 序列化也行);嗯, web service, 如果对方也是 .net 能省却她们的工作量,
即使不是 .net, 解析也不难.
我极力推荐双方遵循 Microsoft Sync Framework 交流数据，你几乎就不要考虑太多自己实现的问题了，做好规则即可。它可灵活自定义数据流向，是否对等，传输逻辑请不要过分理解Sync 同步的含义。它能做的事情实在多得不得了
我的理解和vrhero、wuyi8808的一样
对方需要你们提供一个应用程序API，如果是B/S部署最简单的方式就是发布WebServices。
对于C/S部署，如果上家也是是.net平台可通过建立Remoting或socket向对方送数据，如果不是则有些麻烦了。
我现在也在负责一个winform+SQL2005的C/S项目，远程服务器部署了我写的接受数据的WebService,客户端数据是通过引用这个远程webservice传过去的。但这样的方式并不是winform来提供API，而是使用API...
依我看，lz恐怕得和上家联系一下了
谢谢，那现在可以确定的就是方案一web service我已让同事在分析了。
数据的传输介质，也打算使用XML来进行。
----------------------------------------------------
拿报警数据举例，你的报警数据我理解是一种数据的变更，或行或列，Sync Framwork 理解是一种数据版本的变更。 变更了它就会记录。
对方请求数据，也是根据数据版本的提取逻辑进行处理。是否是它需要的数据
只要下次Sync 按照一个数据版本的逻辑就可以取到自己需要的数据
Sync Framework 早就封装好了，你都不要再设计了
我指webservice 框架\xml 数据封装
Sync Framework , 你搭Host, 人家写Client (代码都没多少行），人家也不需要知道你的接口，按照Sync Framework 进行调用你 Host WebService 即可
web service, xml 都已经封装好了，也不需要人家做什么太多的代码你只要把数据变更，或者说Sync 逻辑做好即可。
Sync Framework 都给你做好了
二、API方案
三、直接节享数据库操作方案(仅限数据交互使用)
以下请指教补充
回复42楼。偷偷的小高兴一下，思路还算没有偏离轨道
我并不推荐拿来就用，假设分析过Sync框架，并且有自己的理解，那当然最好。 单就这个项目来说，它支持了楼主所需要的大部分需求，而且还有余地做今后变更的扩展，何乐不为呢？
框架考虑的比你们的设计周到很多,风险系数也最小，请问是为了实现项目，还是为了科研项目？回复55楼:恩:现在可以确定的就是上家只从我们的软件时提取数据.无需双向交互.
项目是一个科研项目,目前是考虑实现,此贴也算是半个知识讨论贴.仁兄一直提供的Sync 方案,我下午花时间先了解一下,毕竟我知识面太小.完了后,会在一周内对此贴做总结时进行学习及公布.还望你继续关注此贴.同时也希望你对以上其它同胞提出的方案(26楼有个小总结),进行分析,再次描述一个你的个人见解.谢谢.
有 over engineering 之嫌了，在需求变更到来之前，猜测需求，是愚蠢的
等等概念与技术，我们为什么不研究它，分析它呢？非要自己在这里琢磨一个不成熟，不稳定的方案。我觉得理由不充分
呵呵，如果“未来”不需要变动，那么用框架就是一种浪费，部署和维护一个web service也是要成本的吧，学习webservice或者框架也是有学习曲线和学习成本的短时间内应用一个自己并不熟悉的技术，本身也是一种风险...
这不叫猜测需求， 就选择 Sync 框架而言，是为了应用楼主的需求，也是为了今后变更扩展保留余地，它可以解决大部分数据传输、同步的问题，凭我的经验、在这个领域里。你凭什么认为是愚蠢的？
个人认为：如果站在产品的角度可以去想。
站在项目的角度也需要分析一下可能性的需求变更(当然不切实现)。
同仁们能为一种技术的应用而讨论是好事.和气和气.我们都是在讨论技术.还望继续深析一下以上所有楼上提供的方案.第一套webservies方案，已经考虑中……
第二套API也可看是否需要。
第四套Sync Framework
第三套直接公布数据库视图的方案本人在分析中。
注明:平台异构
我认为它是为使用者提供的功能、I/O标准。
如果是不同语言，数据类型上可能存在差异，也许这是个麻烦的事情。
web service上面已经提过了。仅仅是数据的话，数据仓库等也是一种可行的方法。
框架如果不具备稳定性，安全性，它早就被淘汰了？虽然它不可避免也有小弊端。
为什么不能在使用中学习，理解它？ 甚至改造它，创造它？
假设你们都没用过Sync Framework 做过长期开发，我有。
单就这个项目而言，假设自己从底层封装到上层xml封装都要自己实现，风险是大的。假设数据冲突怎么办？
假设连接中断怎么办？
假设出现错误怎么办？
等等等....
光是推荐方案的话，再加一个，如果是sql server 2005，直接上data service，:）楼主啊，方案多了，光考察方案都要花很多时间吧，o(∩_∩)o
http://www.cnblogs.com/healerkx/articles/1521450.html代码可以从google code上面下，
关注解耦，和处理WinForm，Silerlight的线程到UI的回调。
没错，技术讨论嘛，本来没有什么对错PS：貌似先前偶的幽默比较冷～ 囧rz
这个影响到你是否给她提供一个不透明'连接'对象;
还是单次数据请求是独立的.
这方面对效率影响很大, 可以考虑一下数据请求方面的:
小数据包请求, 彼此独立, 频繁请求, 各个请求上下文不同,
不同请求之间有状态区分, 缓存策略.角色扮演一下, 假如你是一个数据提供者,
同一个客户在 5 分钟前刚请求了某个数据,
现在又来要, 你烦不烦?2. 平台问题:
好像没见到你提他们的平台是怎样的.
假如你们的 .net 体系要保露给 C++/win32/MFC 团队,
技术锲合问题, 还有 holy war 的问题考虑过?其实, 如果方案确定了的话, 实现起来往往很简单,
但是前期你要考虑太多事情.
哪里哪里，就是有点实际经验罢了在这里我简单描述下原先Sync Framework项目的一些情况
Host 端（sync service)，Client 端(手持设备）. client 端需要从Host端获取当天的workorder.
完成后再回传到sync service, 更新到数据库中。 这里用到了，单向下载，单向上传，双向（先上传、再下载）等等方式。 我感觉楼主的应用只用到了单向下载。 而不需要回传。
在之前的版本，也有一个自己搞的同步框架，但是问题多多
考虑到网络、稳定性、安全的考虑，我们采用了Sync Framework，效果还是不错的，特别是出了构架，自己可以扩展并且实现很多自己特定的传输模式，这个比较好。
我用我 Sync Framework的理解，来回答下这两个问题。
1. 交换频度，小数据包请求, 彼此独立, 频繁请求, 各个请求上下文不同, 不同请求之间有状态区分, 缓存策略. Sync Framework 都能有效的支持
2. 关于切合。 Sync Framework 的交换格式，还是Web Services+XML 标准的交换格式。 大部分跨语言的的通信方案，这还是这种比较合适。
1.提供编译好的dll程序集，并将定义好的函数和方法进行整理写成API文档，通常是.chm格式的。提供你的上家使用<br />
2.提供WebService接口，使用C#将你个人后台程序的方法，在Webservice中定义清晰完整，所有的跟上家要求的前台部分的方法都给予定义和声明。上家程序中调用你的Webservice接口，并且传递参数返回给对方的就是XML格式的数据集。上家就可以使用了。<br />
C#中的接口是面向对象编程中很有用的概念，计算机程序最终是要解决现实世界的各种问题，它也是在不断的在把现实世界的解决问题方案用计算机进行模拟。举个例子，现在要生产磁带，怎么才能保证不同厂商生产的磁带都能被录音机播放呢，那就需要有相关的标准，磁带多宽，多长，磁性达到多大才能被认出等等，这就会有相应的国际标准，有了标准，那么谁生产的磁带都能被播放，如果不按照标准生产，那产品肯定卖不出去。
那么接口就相当于标准，它只是些技术指标（在代码中就是一些函数签名），不能实际运行的代码，具体的实现是由继承它的类的实例成员来实现的（生产磁带的厂商），按照接口的定义来实现的类是真正运行的代码，也就是你们项目实现的功能，接口是描述这些功能的，你的上家只需要知道你的接口，new一个实例就可以使用你的功能了，不需要知道你实现的细节，计算机技术也是不断在尽量贴近实际世界的运行方式，也是在不断发展的