通过 SOAP 的 MVC 3 存储库模式
感谢您对此的任何帮助。
我们目前正在努力改造一个遗留项目，该项目现在正变得难以维护。因此，我们决定正确规范化数据结构，并在使用存储库模式的 MVC 3 项目中使用 Entity Framework 4 Code First 开发。我们目前面临的问题是，出于安全原因，遗留应用程序托管在我们主要基础设施之外的服务器上 - 因此所有 CRUD 操作都是通过 Web 服务完成的，没有与 MS SQL 数据库的直接连接字符串。
我的“建议”解决方案是定义我的存储库合同，在开发过程中将直接连接到数据库，但一旦部署就不会存在（以后可能有更改的范围）。那么，我提供两个适用于同一合同的具体版本的存储库是否合理。一个使用 LINQ 执行 CRUD 操作（开发以及我们稍后可以迁移到的基础设施），另一个版本使用 SOAP 传递对象（这意味着我的 POCO 需要定义为可序列化）并以这种方式执行 CRUD 操作？
这听起来可行还是有更好的方法来实现这一目标？
谢谢！
appreciate any help with this.
We are currently working on remodelling a legacy project that is now heading towards being too much of a nightmare to maintain. So, we've decided to properly normalise the data structure and use Entity Framework 4 Code First development in an MVC 3 project using a repository pattern. The issue we face at the moment is that the legacy application is hosted on a server outside of our main infrastructure for security reasons - therefore all CRUD operations are done via web services, there is no direct connection string to the MS SQL database.
My "proposed" solution is to define my repository contracts, during development there will be a direct connection to the database but once deployed there won't be (there may be scope to getting that changed later). So, would it be reasonable for me to provide two concrete versions of the repository working to the same contract. One that uses LINQ to perform CRUD operations (development and possible the infrastructure we can move to later) and another version that uses SOAP to pass objects (that would mean my POCOs would need to be defined as Serializable) and perform the CRUD operations this way?
Does this sound feasible or is there a much better way of achieving this?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您负责开发客户端和服务部分，您可以使用一些简单的方法：
通过使用这种方法，您将为这两种情况提供单一存储库实现，并且您的上层逻辑不会改变。远程存储库只会有额外的 Web 服务层。您的存储库必须封装所有数据访问逻辑和查询 = 存储库外部没有 linq 查询，这不是您的体系结构中的问题，因为如果没有您自己的自定义开发或不使用 WCF 数据服务，linq 查询就无法序列化（但它会对您的架构的其他影响）。
顺便提一句。将存储库放置在 Web 服务后面并不常见。更常见的是将整个服务层/业务逻辑放在 Web 服务后面。
If you are responsible for developing both client and service part you can use some simple approach:
By using this approach you will have single repository implementation for both scenarios and your upper level logic will not change. There will be only additional web service layer for remote repository. Your repository will have to encapsulate all data access logic and queries = no linq queries outside of the repository which is not the issue in your architecture because linq queries are not serializable without your own custom development or without using WCF Data Services (but it would have other impacts on your architecture).
Btw. it is not very common to place repository behind the web service. More common is to place whole service layre / business logic behind the web service.