WPF 具有任意、未知的数据库 - 客户端/服务器或桌面应用程序？
我的公司正计划将旧的 Winforms 应用程序转变为 WPF/Silverlight 客户端/服务器应用程序。
拥有小型服务器应用程序的想法是拥有可访问数据库的列表以及可以访问每个数据库的用户类型，而不必在每个客户端的管理控件中管理数据库。此外，如果 SQL 请求由服务器处理并返回结果，那就太好了。
该应用程序应该在任意一组数据库上运行，这些数据库将在服务器上“注册”，并且用户根据其身份验证权限获得数据库列表。然后，他们几乎可以在这些数据库上做人们能想象到的所有事情。系统应该能够处理多达 200 万行。
数据库非常不同，可以有很多，可以是 MS Access、Oracle、SQL Server 等，所以我之前无法将它们全部指定。最重要的是，需要与 SQLite 缓存进行通信。 我已经拥有了 Winforms 应用程序中 SQL 查询所需的一切。
我在想：
1）一个简单的WCF服务器在配置文件中指定每个用户类型的可用数据库。
2) 指定可以对服务器进行的所有必需的 SQL 查询的接口。
3）客户...
想法是： 客户端-服务器应用程序，其中客户端使用 WCF 服务通过调用服务方法对表执行 SQL 查询（INSERT、UPDATE、SELECT 等）。
理想情况下，该服务应该可供 WPF 和 Silverlight 应用程序使用。
这是要走的路吗？我可能想利用哪些现有的格式、通信、服务等技术。
如果有问题，我会考虑回到桌面应用程序，但如何缓解每个客户端的用户类型/数据库访问问题？
My company is planning to turn an older Winforms application into a WPF/Silverlight Client/Server app.
The idea of having a small server app is to have a list of the accessible data bases combined with the user type that may access each of the databases, instead of having to manage databases in each client's admin control. Additionally, it would be great if the SQL request would be handled by the server which would then return the result.
The app is supposed to work on a arbitrary set of databases which will be "registered" with the server and users get a list of databases according to their authentication rights. They can then do practically everything on those databases what one can imagine. The system should be able to handle up to 2 million rows.
The databases are very different, there can be many of them, they can be MS Access, Oracle, SQL Server etc., so no way for me to specify them all before. On top of that, communication with a SQLite cache is needed.
I already have everything I need for the SQL queries from the Winforms app.
I was thinking:
1) A simple WCF server specifying in a config file the available databases per user type.
2) Interface that specifies all necessary SQL queries that can be made to the server.
3) Client...
The idea is:
a client-server application, where the client uses WCF services to execute SQL queries (INSERT, UPDATE, SELECT, etc.) on tables by invoking services methods.
The service should ideally be consumable for both the WPF and the Silverlight app.
Is that the way to go? Which exisiting technologies might I want to make use of regarding formats, communication, services etc.
If that is problematic, I would consider going back to a desktop app, but then how to ease the user type/database access problem for each client?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会坚持使用 ADO.NET 并从 DbProviderFactory 类开始。这将使您可以根据提供商使用工厂设计模式提供的信息确定正确的数据库访问。因此，您不必为每种数据库类型和数据库创建专门的对象，而是可以使用 DbProviderFactory 抽象该逻辑。
下面的链接显示了一些示例： http:// msdn.microsoft.com/en-us/library/wda6c36e(v=VS.100).aspx
I would stick with ADO.NET and start with the DbProviderFactory class. This will let you determine the proper database access based on information supplied by the provider using the Factory Design Pattern. So instead of having to create a specialized objects for each database type and database, you can abstract that logic with the DbProviderFactory.
Here's a link that shows some examples: http://msdn.microsoft.com/en-us/library/wda6c36e(v=VS.100).aspx