如何将 ADO.net 本地数据层面向未来迁移到基于 Web 的接口（Web 服务或 REST）？
背景：我现在正在开发一个 .NET WinForms 应用程序（C#），并使用 ADO.net 数据库作为数据层。
问题：我现在如何开发它，以便轻松迁移到通过 HTTP Web 服务或 REST 接口抽象数据层的模型？
例如，是否仅使用带有工厂的标准 C# 接口来获取接口的具体实现，其中使用 ADO.net 是最好的？
谢谢
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
实际上你想要做的是将你的 2 层应用程序（应用程序 <--> 数据库）更改为 n 层系统（应用程序 <--> 应用程序服务器 <--> 数据库） ）。
这是一个复杂的更改，因为您必须考虑安全性、业务逻辑和一切。
一种想法可能是使用第三方库，例如 DataAbstract。这是一个完整的 n 层框架，仍然允许您使用 LINQ 等功能来连接远程数据源，并使 n 层开发变得非常容易。它还提供了一个 Web 服务接口，可以从任何来源轻松访问应用程序层内的业务逻辑。更进一步，它为您提供了 iPhone 和 Windows Mobile 的客户端库，允许您更快（因为二进制）访问该层。仅对于无法使用 DataAbstract 的平台，您才需要 Web 服务接口。
Actually what you wanna do is to make your 2-tier application (Application <--> Database) change into an n-tier system (Application(s) <--> App Server <--> Database).
This is a complex change because you have to think of security, business logic and everything.
One Idea could be to use a third-party library like DataAbstract. This is a complete n-Tier framework, still allowing you features like LINQ to a remote data source and making n-tier development really easy. It also provides a web-service interface to easily access your business logic within the application layer from any source. Going further it provides you with client libraries for the iPhone and also windows mobile that do allow you a faster (because binary) access to the layer. You would need the web service interface only for platforms where DataAbstract is not available for.
你说得一针见血——这是关于抽象的。现在就开始从业务逻辑中抽象出特定于存储的语义。开发一个干净的、面向对象的 DAL 并通过它执行所有 CRUD/查询操作，虽然您的对象模型（或域模型，如果您想认识两者之间的区别）可以使用具体类，但您的 DAL 操作应该定义在一个界面中。是否使用工厂取决于您的特定用例，但如果您在开发时考虑到这种抽象，那么采用控制容器反转并通过依赖注入处理这种连接是有意义的。 那里 有 很多 至 选择来自。
You've hit the nail on the head - it's about abstraction. Start out right now by abstracting away from storage-specific semantics in your business logic. Develop a clean, object-oriented DAL and do all CRUD/Query operations through it, and while your object model (or domain model, if you want to recognize a difference between the two) can use concrete classes, your DAL operations should be defined in an interface. Whether you use a factory depends on your particular use case, but if you're developing with this sort of abstraction in mind, it makes sense to adopt an inversion of control container and handle this sort of wiring by dependency injection. There are lots to choose from.
您永远不会想使用 REST 接口来抽象 DAL。 REST 接口是直接向“用户代理”公开的接口。您永远不会希望您的业务层通过 REST 消费数据。
唯一的例外是，如果您的主要目标是将原始数据公开给某些远程第三方。
You would never want to abstract a DAL with a REST interface. A REST interface is something that you expose directly to a "User Agent". You would never want your business layer to consume data via REST.
The only exception is if your primary goal is to expose the raw data to some remote third party.