针对具有更改模式的数据库开发应用程序



我正在开发一个ASP.NET MVC应用程序,它本质上是一个基于web的报告工具。我为报告提取的数据库仍在开发中,也就是说,它的模式可能会发生变化,但如果发生了变化,它应该只会发生最小的变化。

与其等待数据库模式变得具体,我决定现在可以将我的数据模型定义为POCO,并使用存储库接口来检索数据(以及用于IoC的Ninject)。这样,我现在可以使用测试数据构建我的报告视图模型,然后再实现我的存储库以使用真实的数据库,理想情况下不必更改我的模型->视图模型映射。

第一个问题是术语:由于这是一个报告应用程序,我的DB交互是只读的。存储库是这里使用的正确术语吗?

第二个问题是:这是一个体面的方式来进行这个项目吗?如果创建一个报告应用程序,而您的后台数据库模式并不具体,您将如何做到这一点?

我的DB交互是只读的。存储库是这里使用的正确术语吗?

不是。存储库本质上是在底层数据提供者和使用它的任何代码之间操作的门面,通常通过接口公开所有可用的操作。它通常封装底层提供者(EF、NHibernate等),因此使用代码不知道持久性机制是如何实现的。

您希望它是"只读"的,这是一个实现问题。如果你不需要写任何东西,我甚至不会用ORM。这太夸张了。只需使用存储过程,如果您愿意,可以使用Massive或Dapper之类的简单组件来包装它。然后,您可以通过一个非常简单的存储库公开这些存储过程,该存储库只公开这些查询,而不公开其他内容。以防您想切换到其他东西,如经典的ADO.NET.

使用SPROC有一个额外的好处,您可以伪造存储过程的结果。例如,不要让它进入实际的表,而是以这样一种方式伪造结果集,即结果是你所期望的。

然后,当模式准备好时,更新SPROC,假设您"伪造"正确,那么您的测试应该仍然通过。当然,如果需要新的字段,则可能需要更改某些代码。但在这里使用SPROC意味着你的查询将非常快(没有ORM膨胀,接近金属),这也有助于你在这里的场景。

我可能会受到"存储过程是史前的"追随者的攻击,但在你的场景中我会这么做。

最新更新