代码之家  ›  专栏  ›  技术社区  ›  Brian

设计数据库层DLL以支持插入替换

  •  1
  • Brian  · 技术社区  · 14 年前

    我在考虑主要通过LINQ使用数据库与主要通过存储过程使用数据库之间的区别。存储过程的优点是,您可以更改任何单独的存储过程,而无需重新编译/重新发布应用程序。所以,我在考虑如何通过创建一个解决方案来拥有类似的能力,其中所有面向数据库的代码都在一个单独的项目中,使用有趣的东西,如dbml文件等。显然,如果在一个替换的LINQ函数内部填充垃圾,替换将导致问题,但存在这种缺点。

    我想出的主要规则是:

    • 如果数据库模型更改,则是重新编译的时候了。
    • 防止任何签名更改。不应删除现有的公共方法。

    那么,这个想法有意义吗?是否应该使用任何策略使其合理安全(即,除了在不重建应用程序的情况下编辑存储过程所带来的风险之外,不增加太多新的风险)?

    2 回复  |  直到 14 年前
        1
  •  0
  •   Pieter van Ginkel    14 年前

    您所描述的称为存储库,它们是域驱动设计的一部分。 结合ORM(NHiBurnter,实体框架),这将给您带来一些灵活性。

    我不确定是否有可能有一个数据库层,它是从你的代码基分开,这样你可以完全取代你的DLL的,但上面可能是一个起点,以达到那里。

        2
  •  0
  •   ChrisLively    14 年前

    可以将数据库层分开,这样您就可以部署新的DLL。我们对项目采用了类似的方法。

    注意,我们没有实现LINQ或任何其他ORM工具。相反,我们的DAL代码使用通过企业库提供的常规数据库访问。

    在添加这些字段时,我们决定是否需要它们。如果它们是,那么这意味着必须修改主代码以支持这一点,并将整个部署在一起。如果没有,那么我们可以将新的数据访问程序集与主代码库分开部署。