我正在构建一个有两个选项的程序：离线和在线存储选项。在线内容不是问题，从来没有，而且可能永远不会。为了让事情变得更简单，我使用实体框架和在线数据库来完成所有 CRUD。
离线选项是我遇到问题的地方。我尝试添加本地 SQL 安装作为安装包的一部分，但它在某些计算机上失败，具体取决于我使用的 SQL 版本，有些人根本无法安装它......老实说，我不知道我希望经历这些只是为了让人们安装该程序。我想做两件事：
1）存储数据。我目前认为 Linq to XML 是我最好的选择，不需要安装任何额外的东西，但是有没有什么方法可以将实体映射到程序中处理 XML CRUD 的类？
2）同步数据。我想我会使用同步框架，但同样，由于后台没有正常的数据库，这有点痛苦。
非常欢迎任何帮助/建议/评论，如果有更简单的方法来完成这一切，请告诉我。
I'm building a program which has two options: an offline and an online storage option. The online stuff isn't a problem, never has been and probably never will be. To make things a little more simple, I am using the Entity Framework with my online database to do all of my CRUD.
The offline option is where I'm having a problem. I tried adding a local SQL install as part of the install package, but it was failing on certain computers depending upon which version of SQL I was using, some people just couldn't install it at all... honestly, I don't want to be going through that just to get people to install the program. I want to do two things:
1) Store the data. I'm currently thinking Linq to XML is my best bet with nothing extra to install, but is there any way to map the entities to classes within the program that would take care of the XML CRUD?
2) Sync the data. I'm thinking I'll use the Sync Framework, but again, with no normal database in the background, it's a bit of a pain.
Any help/advice/comments very welcome, if there's a much easier way of doing all this, please let me know.
发布评论
评论（1）
我很高兴听到您已经解决了同步逻辑的问题。这就是让我彻夜难眠的一点。在这种情况下，
GUID是您的朋友。我从未尝试过使用 1 个针对不同数据源的
ObjectContext。也许您可以使用 OLEDB 作为您的提供者来完成一些巧妙的事情。我会沿着那条路走一点。但我怀疑你会发现它带来的麻烦多于它的价值。我建议遵循 存储库模式。然后您只需实现一个
XMLRepository和一个SQLRepository即可。这可能意味着一些边界双重编码。但是针对XML的查询与针对数据库的查询有其自身的问题。因此，根据您的具体情况，我认为违反 DRY 原则可能是合理的。另外，我承认这完全是主观的，但令我震惊的是，实体框架对于可以轻松保存在 XML 中的关系模型来说太过分了。我只是好奇您是否考虑过使用 LINQ-to-SQL。如果是这样，是什么说服您选择 EF 的道路？
I'm glad to hear you've got something figured out for the syncing logic. That's the bit that would keep me up at night.
GUIDs are your friend in a situation like this.And I've never attempted to use 1
ObjectContexttargeted at different datasources. Maybe you can pull off something slick usingOLEDBas your provider. I'd go a little down that road. But I suspect you'll find it's more trouble than it's worth.I recommend following the Repository Pattern. Then you can just implement a
XMLRepositoryand aSQLRepository. This may mean some borderline double coding. But queries againstXMLversus a database have their own concerns. So, depending on your specifics, I think violating the DRY principle may be justified.Also, and I acknowledge this is completely subjective, it strikes me that the Entity Framework is overkill for a relational model that can be easily persisted in XML. I'm just curious if you considered using LINQ-to-SQL. And if so, what convinced you to go the way of EF?