使用 ORM 设计 asp.net MVC 应用程序以及未来迁移到 NoSql
刚刚开始一个新的 ASP.NET MVC 解决方案，需求之一是能够在后期扩展到潜在的数百万用户。
我计划使用一个公开 IQuerable 的通用存储库，并在服务/应用程序级别使用 linq（我知道这不是纯粹的 DDD 方法，但这不是争论:)）。我正在计划 EF 作为 ORM 进行数据访问（使用分布式缓存作为二级缓存，以在某种程度上实现可扩展性）
我将面临的问题是所有这些 linq 查询与任何未来的 NoSql linq 提供程序都不兼容（连接不太可能）在 NoSql linq 提供程序中受支持）。 但我愿意冒着必须重新考虑所有这些 linq 查询的风险，只要它们都位于一个地方：服务/应用程序层。
什么是更好的方法？有什么建议吗？
Just starting a new asp.net mvc solution and one of the requirements is the ability to scale for potentially millions of users at later stage.
I'm planning to use a generic repository that exposes IQuerable and use linq in the service/application level (I know It's not a pure DDD approach but this is not the debate :) ). I'm planning EF as ORM for dataaccess (with a distributed cache as second level cache to acheive the scalability at some extent)
The issue I will be facing is all those linq queries not compatible with any future NoSql linq provider (The Joins are unlikely to be supported in NoSql linq provider).
But I'm willing to take the risk of having to rethink all those linq queries as long as they are all located in one place : the service/application layer.
What would be a better approach? any recommandation ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
NoSQL 数据库无法解决 RDBMS 无法解决的问题。只有精心设计的桌子才能做到。
我会从一开始就使用像 RavenDb （因为你在 .NET 中）这样的 NoSQL 解决方案来减少开发时间，而不是稍后再切换。
如果您希望应用程序能够扩展，请使用 CQRS。从一开始就不需要外部查询缓存。只需创建接口，以便稍后可以切换到外部缓存（或某些人所说的查询数据库）。
A NoSQL database wont solve problems that a RDBMS can't. Only well designed tables can.
I would use a NoSQL solution like RavenDb (since you are in .NET) from the start to decrease the development time and not switch later on.
Use CQRS if you want your application to scale. No need for an external query cache from start. Just do the interfaces so that you can switch to an external cache (or query DB as some call it) later on.