做.NET的童鞋进
现在有这样一个问题，要实现2个程序间的数据共享。一个程序是WinForms，另一个WPF。2个程序有各自的数据库，但数据库结构不同。具体点，在A可以添加客户，及其客户相关数据（B也可以添加数据，但不能从B激活共享状态），A可以运行B。如果从A运行B，这些在A添加的数据与B共享，在B可以对数据继续操作。如果A，B共享数据，则在任何一方对数据的改变都自动改变另一方的数据。
一种方法是把A的数据export到本地，然后B import数据。这不是我想要的解决方案。
另一种是用共享数据库，但必须用timer访问共享数据库，看有没有数据变化？如果只能用timer，那应该也不是一个最优解决方案？
我想的解决方案是用WCF，用publisher/subscriber，每个程序分别是另一个程序的publisher和subscriber。对Webservice不是很熟悉，不知道各位童鞋有什么建议。 本帖最后由 hauke 于 2013-2-17 10:33 编辑
上个UML看看 。。。
你看看这个文章有用吗
http://bbs.csdn.net/topics/310103579 楼主啊，我问个题外话啊，你做好的.net程序，给客户装的时候，让程序脱离.net运行吗，这样的软件都是有版权的啊，都好贵！ hauke 发表于 2013-2-17 11:01 static/image/common/back.gif
楼主啊，我问个题外话啊，你做好的.net程序，给客户装的时候，让程序脱离.net运行吗，这样的软件都是有版权 ...
你购买了vs.net，编译出来软件，是可以商用的吧。 而且如果是免费 express 版本编译出来的，也 可以商用的 吧。。。 keepfeeling 发表于 2013-2-17 11:08 static/image/common/back.gif
你购买了vs.net，编译出来软件，是可以商用的吧。 而且如果是免费 express 版本编译出来的，也 可以商用的 ...
晕，我说的是让客户机脱离.net，这方面的软件都是要钱的啊 。。。
另外免费 express 版本编译出来的版本不能用于商用！ 什么数据库？
一般这种情况可以尝试价格Trigger看看 本帖最后由 雪候鸟 于 2013-2-18 22:26 编辑
你用什么数据库做共享，不同的数据库实现手法不一样，你可以尝试用数据库本身的锁机制来实现。如果不想用数据库的锁机制，可以考虑用一个表级或者行级的修改计数器或者timestamp来做(看你的控制粒度需求)，也就是类似于乐观锁的做法。
本帖最后由 并非如此 于 2013-2-19 09:39 编辑
最佳方案
首先，真要想解决这个问题，应该进行数据库重构，用wcf作为数据的独立存储，和逻辑处理层， 至于你有多少个外部应用(winform,wpf,asp.net...）是无所谓的, 这样才能真正保证数据的完整性和一致性。
次佳方案
如果你的客户，非要保持现有数据库，那么如你所说，利用wcf作为数据操作抽象层实现publisher/subscriber架构， 下面的例子很好的解释了这种模式。
http://www.codeproject.com/Articles/22796/WCF-Implementation-of-the-Publisher-Subscriber-Mod
如果原来的应用是直接读取数据库的，那么要把他们读取数据库的模块独立出来，放到wcf中，所有的相关应用，用统一的数据库操作接口来操作数据库，你一样能保证数据的完整性和一致性， 前提就是没有其他的操作接口，只有唯一的，统一的操作接口。
最sb的方案,
原来的操作不便变，只把共同操作的部分独立出来，这种方案，相对较快的解决现有问题，但是未来的隐患是无限的，后面的工作会很恶心，很烦人，非常不利于以后的拓展及维护。
楼上说的很详细，多谢。
看起来要用最sb的解决方案了。公司现在只需要一个临时解决方案，要求保持部分数据一致性。两个应用准备在未来3年合为一个应用，把winforms应用作为一个module用wpf重写并集成在wpf应用。
感谢大家的回复。准备拿出两天看看WCF的文档，扫了下MSDN，内容并不多。另外我想看看是不是p2p是这种情况的合适解决方案。 媛珊娃娃 发表于 2013-2-19 13:45 static/image/common/back.gif
楼上说的很详细，多谢。
看起来要用最sb的解决方案了。公司现在只需要一个临时解决方案，要求保持部分数 ...
学习了。
我想问楼主，你觉得能有楼上这么样的思路，水平，至少要多少年.Net 经验。 并非如此 发表于 2013-2-19 09:35 static/image/common/back.gif
最佳方案
首先，真要想解决这个问题，应该进行数据库重构，用wcf作为数据的独立存储，和逻辑处理层， 至于 ...
这个要赞一下，说得很清楚。最佳方案和次佳方案其实都很费劲，但是最佳方案在结构上清晰很多，publisher/subscriber架构当时公司一个元老级的同事实现过，我看code看的云里雾里，其实要用最佳方案来实现就没有那么复杂，但是有时候没办法，客户不想改变数据库。 今天突击了下WCF，感觉构架并不难，主要工作在服务设置上，当然可能有点分布式系统的知识会对理解这个框架有很大帮助。不过悲催的是，头儿今天告诉我，这个解决方案也要适用我们软件的上一代版本，那个版本运行在xp系统上，只装了.NET 2.0，我们当然不能让客户自己去装3.0后版本。看来要考虑ASP.NET WS 或者 Remoting了。
至于做多长时间才能达到那个高人的水平，因人而异吧。如果你更倾向于做构架的话，多留意各种技术和辅助开发程序，构架方面进步就会很快。而更重视对框架的熟悉度的话，实现程序速度就快很多。个人感觉啊，请不要拍砖。 本帖最后由 媛珊娃娃 于 2013-2-19 23:56 编辑
如果各位童鞋有兴趣技术讨论的话，我又要请教大家了。今天接到另一个任务，就是那个winforms程序（唉，8年开发了3代产品了，而且不是info出身的人写的代码，所以代码有点儿惨不忍睹），公司准备对某些客户做GUI个性化，不过不是什么大的改变，也就是换个logo，改变个颜色等等小变化，大的布局不变。头儿的意思是要一个版本适用所有用户，也就是说，普通用户保持GUI不变，VIP可以在一定范围内定制界面。另外一个比较重要的前提是，我们卖的产品是装了我们软件的电脑，我们可以决定在电脑上装哪个版本的软件，但我们不想为不同的客户做不同的版本，这样会出现维护问题。
我的想法是用xml保存客户要改变的控件名及其属性和值。初始化控件时根据xml数据利用reflection改变控件属性值。
另外我觉得类Visual Studio的property window很有意思，比如说给一个form定义不同的布局状态作为属性，在property window可以改变属性值切换布局。但这个解决方案并不适合，因为即使是VIP，他们也只要求适合他们的布局，而不是动态布局。
大家还有什么好的解决方案，欢迎讨论。 隔行如隔山。。。听起来云里雾里的。。 媛珊娃娃 发表于 2013-2-19 23:07 static/image/common/back.gif
如果各位童鞋有兴趣技术讨论的话，我又要请教大家了。今天接到另一个任务，就是那个winforms程序（唉，8年开 ...
只是小的改变而以，web应用的话css基本上就能满足需要了吧
如果是PC应用程序的话，感觉那种换皮肤的功能就够了吧
界面的动态布局和控件的动态载入相对复杂一点，可以考虑创建个个性化配置文件
个人觉得 并非如此 发表于 2013-2-19 09:35 static/image/common/back.gif
最佳方案
首先，真要想解决这个问题，应该进行数据库重构，用wcf作为数据的独立存储，和逻辑处理层， 至于 ...
我觉得数据同步，如果能够共享数据库是最好的解决方案。其他的代价都太大 不明白，如果用共享数据库，为什么还用timer? 你要实时通知变化吗 sbtree 发表于 2013-2-20 12:25 static/image/common/back.gif
只是小的改变而以，web应用的话css基本上就能满足需要了吧
如果是PC应用程序的话，感觉那种换皮肤的功能 ...
不是web，刚才仔细看了下客户要求，不同客户可能要不同的控件布局。看来真的需要winforms版的css了。
在codeproject找到了个winforms版的css，不过不知道是不是对所有控件的所有属性支持，不是的话就只能自己扩展这些功能了。我不能发URL，有兴趣的童鞋自己在gongle搜winforms css就马上能找到链接。 雪候鸟 发表于 2013-2-20 14:42 static/image/common/back.gif
不明白，如果用共享数据库，为什么还用timer? 你要实时通知变化吗
共享某些数据，但不共享数据库。 雪候鸟 发表于 2013-2-20 14:37 static/image/common/back.gif
我觉得数据同步，如果能够共享数据库是最好的解决方案。其他的代价都太大
同意，数据来源唯一本身就保证了不同应用之间的数据一致性和同步性，在这方面就可以省去不少维护的工作了 媛珊娃娃 发表于 2013-2-20 15:36 static/image/common/back.gif
共享某些数据，但不共享数据库。
没搞明白，你的一个方案是共享数据库，然后打算用timer. 现在又说共享某些数据，不共享数据库了。需求不清楚大家没法给你出主意了。 本帖最后由 媛珊娃娃 于 2013-2-21 00:26 编辑
雪候鸟 发表于 2013-2-20 20:04 static/image/common/back.gif
没搞明白，你的一个方案是共享数据库，然后打算用timer. 现在又说共享某些数据，不共享数据库了。需求不清 ...
2个程序都各自有自己的数据库，要实现2个程序的部分数据共享，而不改变原有数据库。
共享数据库是我设想共享一个各自数据库之外的数据库来解决共享数据问题。其实共享什么解决这个问题都应该是无所谓的。不过是数据载体而已，比如说XML。
这个问题那个高人也已经详细解答了。当然我不能决定公司战略，所以虽然有最优解决方案，也不能自己去实施。现在公司已经确定用WCF了，实现p2p实现共享。
谢谢大家了。 本帖最后由 雪候鸟 于 2013-2-21 00:49 编辑
媛珊娃娃 发表于 2013-2-21 00:23 static/image/common/back.gif
2个程序都各自有自己的数据库，要实现2个程序的部分数据共享，而不改变原有数据库。
共享数据库是我 ...
有2个数据库也麻烦不到哪里去。在A和B的数据库中分别建立A到B和B到A的数据库连接。建立数据库连接就一个命令的事情简单的很。然后再A的表上做个触发器，当往A的表内写东西的时候这个触发器经过数据库连接把这些数据写到B的表中。B也同理。互相保持对方数据同步。这个不论效率还是保证数据的一致性上都不错。 雪候鸟 发表于 2013-2-21 00:46 static/image/common/back.gif
有2个数据库也麻烦不到哪里去。在A和B的数据库中分别建立A到B和B到A的数据库连接。建立数据库连接就一个 ...
这两个数据库未必在同一个系统下，有可能是两个local的数据库运行在不同环境里，之间未必能互相通信。
还有即使在同一系统下，两个不同的Schema下的数据库直接通过触发器和存储过程来保证数据的同步，在我看来是件危险的事情，如果是我设计的架构，我不会采用， 数据库之间的直接通信方法，而是通过应用层，将其隔离，这样的结构更加清晰，也容易维护和拓展，当然我不是数据库方面的专家，数据库优化方面的知识比较浅薄，但是对于性能方面，对我的客户来说，一般只要够用就好，为了结构的简单化，哪怕加大一些系统开销，我也认为是值得的。 本帖最后由 雪候鸟 于 2013-2-21 14:57 编辑
并非如此 发表于 2013-2-21 09:31 static/image/common/back.gif
这两个数据库未必在同一个系统下，有可能是两个local的数据库运行在不同环境里，之间未必能互相通信。
...
用数据库连接不需要数据库不需要在同一个系统，可以一个在中国一个在德国，只要防火墙让通过就行:)。schema不是数据库，至少在oracle和db2中都不是. 数据量大点更新频繁点，应用层得累死。我们这里java的应用也要处理类似的情况。一开始也是应用层通信的，最后把应用层的queue都写爆了，都来不及处理。很多应用层看似不错很完美的架构，在海量数据或者频繁更新面前都是无解。 雪候鸟 发表于 2013-2-21 14:55 static/image/common/back.gif
用数据库连接不需要数据库不需要在同一个系统，可以一个在中国一个在德国，只要防火墙让通过就行:)。sc ...
你所说的依然是同一环境内，也就是同样的数据库系统，只是地点不同，分布式而已，但是不同数据库系统之间多数是不能直接通讯的。
第二点，我说过我不是数据库优化方面的专家，所以在性能问题上，我承认你是对的，但是多数应用和你说的海量数据没有关系，当然这个问题要具体情况具体分析，我相信楼主公司的数据量没有大到那个地步， 通过楼主的描述，我猜想，他们公司的软件产品，可能属于工控类的。为了控制他们公司的硬件产品而附赠的，所以楼主公司，应该不是软件为主的公司，应该是生产电子仪器，或是大型电子机械的公司。 并非如此 发表于 2013-2-21 17:33 static/image/common/back.gif
你所说的依然是同一环境内，也就是同样的数据库系统，只是地点不同，分布式而已，但是不同数据库系统之间 ...
oracle的数据库和db2通过数据库连接没有问题的，所以我想只要是比较知名的数据之间应该都可以，因为数据库连接只不过是个基本功能。如果数据量小，而且能够肯定将来也不会增长太大，走应用层从审美上当然更漂亮些。 本帖最后由 雪候鸟 于 2013-2-21 21:12 编辑
sbtree 发表于 2013-2-20 15:39 static/image/common/back.gif
同意，数据来源唯一本身就保证了不同应用之间的数据一致性和同步性，在这方面就可以省去不少维护的工作了
数据库不应该只是被动的承受来自应用层的修改，应该有自己主动地一面，来保证数据的一致性。该数据层解决的问题就不要推倒应用层。现在大多数都推到应用层做我觉得原因主要是应用层开发人员多，所以习惯性的思维让很多数据问题都是在应用层解决。并且最近多年流行的贫血pojo的开发思维让人觉得，数据模型就是被动的，只不过是容器，其实充血的数据模型更能保证数据的一致性。估计做开发的现在多半都要做support, 很多support中的问题查来查去是数据的datenschiefstand, 很多跟贫血pojo开发思想有关。 本帖最后由 媛珊娃娃 于 2013-2-22 01:44 编辑
并非如此 发表于 2013-2-21 17:33 static/image/common/back.gif
你所说的依然是同一环境内，也就是同样的数据库系统，只是地点不同，分布式而已，但是不同数据库系统之间 ...
没错，我们的确不会有海量数据，说白了，我们要实现的是应用之间的通信。 雪候鸟 发表于 2013-2-21 21:02 static/image/common/back.gif
数据库不应该只是被动的承受来自应用层的修改，应该有自己主动地一面，来保证数据的一致性。该数据层解 ...
的确每个层应该满足自身的需求，这也是我的编程理念，不过你说的trigger我的确不懂，能否指教下如果在2个sql server数据库下利用trigger达到数据共享。
页:
[1]
2