我正在开发一个ASP.NET MVC应用程序，它本质上是一个基于Web的报告工具。我正在为我的报告提取的数据库仍处于开发阶段，即它的架构可能会发生变化，但如果确实如此，它应该只会发生最小的变化。
我没有等待数据库模式变得具体，而是决定我现在可以将我的数据模型定义为POCO，并使用存储库接口来检索数据（以及Iin的Ninject）。这样，我现在可以使用测试数据构建我的报告视图模型，然后实现我的存储库以使用真实数据库，理想情况下无需更改我的模型 - ＆gt;视图模型映射。
第一个问题是术语：由于这是一个报告应用程序，我的数据库交互是只读的。存储库是否适用于此处使用？
第二个问题是：这是一个体面的方式去做这个项目吗？如果你有来创建一个报告应用程序，你的备份数据库架构不具体，你会怎么做？
答案 0 :(得分：0)
我的数据库交互是只读的。存储库是否适用于此处使用？
不是真的。存储库本质上是在底层数据提供程序和任何代码消耗它之间运行的外观，通常通过接口公开您提供的所有操作。它通常包装底层提供程序（EF，NHibernate等），因此消耗代码不知道如何实现持久性机制。
您希望它“只读”的事实是一个实现问题。如果你不需要做任何写，我甚至不会打扰ORM。这太过分了。只需使用存储过程，如果您愿意，可以使用Massive或Dapper之类的简单组件进行包装。然后，您可以通过一个非常简单的存储库公开这些存储过程，这些存储库只公开这些查询，而不是其他任何事以防您想要切换到其他类似经典ADO.NET的东西。
使用SPROC有额外的好处，您可以伪造存储过程的结果。例如，不要让它去实际的表格，而是假设结果集的结果是你期望的结果。
然后当架构准备就绪时，更新SPROC并且您的测试应该仍然通过，假设您正确“伪造”。当然，如果需要新字段，则可能需要更改某些代码。但是在这里使用SPROC意味着你的查询将超级快（没有ORM膨胀，接近金属），它也有助于你的场景。
我可能受到“存储过程是史前”粉丝的攻击，但这就是我在你的场景中所做的。