什么因素会影响我在新项目中使用的数据访问层?

就像软件项目中的所有选择一样:这取决于… 但在我看来,最重要的因素是项目的环境。

这包括(我不声称此列表在任何情况下都是完整的):

• 开发团队和维护团队中的可用技能(如果不同)
• 所需功能
• 由客户端设置的约束(并非所有客户端都支持所有可用的技术)。这当然是您在逐步替换遗留系统或将新系统引入环境时应该考虑的事情)
• 立法规定的限制

希望这对你有帮助。

需要记住的一件重要事情是,数据库不一定只是应用程序的后备数据存储(隔离)。其他应用程序和过程最终可能需要访问数据库,尤其是在大型或__Enterprise_数据库(或应用程序)中,尤其是在有足够时间的情况下。

必须考虑:

此外,一些设计考虑是合理的。您是为更快的选择进行调优,还是为更快的写入进行调优?一种数据访问设计可能比另一种更好。

我并不是说只有一颗银弹,但我要注意的是,任何数据访问设计模式都需要“大局”思想——它能解决今天的问题吗?你能合理预测未来的需求吗?

此外,您将提供一个外部API或一些用于一致数据访问的框架吗?会直接或间接暴露吗?

我认为,实体框架/Linq to SQL、传统存储过程和其他工具(如nhibernate等)都有一个地方,但您应该首先证明和合理化技术选择,并努力确保它适合当前和未来的需要。

编辑:对不起,我忘了一个大问题:可维护性。一些模板驱动的解决方案在模式更改后能够重新生成DAL方面比其他解决方案(如手写存储过程)提供了一些不错的优势。值得权衡一下生产率的提高和缺点。

我认为在你最初的帖子和诺贝特的补充文章之间,你已经涵盖了几乎所有的内容。从绝对约束开始(记住,这仅仅是因为客户对某件事说了“不”,即使他们说这是绝对的,但并不意味着你不能帮助他们改变主意…)。一旦你缩小了绝对约束的范围,看看其他的东西。

有一件事似乎被遗漏了,那就是灵活性。例如,如果我试图在两种相似的技术之间进行选择,我知道一种技术可以支持可更新的视图,而另一种技术则不能,即使当时我完全不需要可更新的视图,我仍然倾向于“以防万一”的方法。

我只想两件事。第一个问题是我是否会有如此多的数据以至于其他事情都很重要。如果您不将数百万行放入表中,那么您将使用哪种技术可能无关紧要,因为它们的工作速度都足够快。

第二件事是我是否可以使用LINQ,因为我发现使用LINQ(到SQL,到实体,到llblgen,这无关紧要)查询数据库给了你两件重要的事情。第一个问题是很容易编写查询;第二个问题是,在需要LINQ的两个框架之间切换比较容易,以防需求发生变化。