哪些因素会影响我在新项目中使用的数据访问层？答案

【问题标题】：What factors should effect the Data Access Layer I use on a new project?哪些因素会影响我在新项目中使用的数据访问层？
【发布时间】：2010-09-17 02:23:01
【问题描述】：

我将教一个班级学生，我需要解释哪些因素会影响您对数据访问技术的决定。我熟悉许多数据访问方法，例如 Typed Data Sets、Linq to SQL、Linq to Entities、.netTiers、LLBLGen，以及使用 SQL 连接对象和命令对象的自定义调用。我的一些客户只允许使用存储过程，他们不会讨论其他任何事情。我的一些客户还没有准备好安装 .NET 3.5。一些客户端在任何 Web 应用程序中都需要一个中间 Web 服务层。大多数时候我使用类型数据集和自定义 Web 服务，或者我使用带有 CodeSmith 的 .netTiers。我还应该考虑什么？

【问题讨论】：

编辑：“哪些因素会影响项目数据访问层的选择？”

标签： .net asp.net data-access-layer

【解决方案1】：

要记住的重要一点是，数据库不一定只是应用程序的后备数据存储（孤立地）。其他应用程序和进程最终可能需要访问数据库，尤其是在大型或“企业”数据库（或应用程序）中，尤其是在有足够时间的情况下。

重要的是要考虑：

ETL/加载/迁移

外部集成/同步 (BizTalk/SSIS)

被其他应用程序（尤其是网站、移动应用程序等）重复使用

安全/攻击面（一种方法的安全性低于另一种方法吗？）

维护任务

可用性 - 数据库会 24/7 全天候使用吗？一种方法是否会比另一种方法提供更好的可用性，等等。

另外，一些设计考虑是有序的。您是否正在调整更快的选择或更快的写入？一种数据访问设计的性能可能比另一种更好。

我并不是说只有一个灵丹妙药，但我要提醒的是，任何数据访问设计模式都需要“大局”思维——它会解决今天的问题吗？您可以合理预测的可能是明天的需求?

另外，您是否会提供外部 API 或一些框架来实现一致的数据访问？会直接暴露还是间接暴露？

我认为，Entity Framework/LINQ to SQL、传统存储过程和其他工具（如 NHibernate 等）都有一席之地，但您应该首先证明和合理化技术的选择，并尝试确保它是适合现在和未来的需求。

编辑：抱歉，我忘记了最重要的一点：可维护性。一些模板驱动的解决方案为您提供了一些不错的胜利，因为能够在模式更改后重新生成 DAL，而不是其他解决方案（如手写存储过程）。值得权衡生产力收益与劣势。

【讨论】：

【解决方案2】：

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

这包括（我并不声称这个列表是完整的）：

开发团队和维护团队的可用技能（如果不同）
所需功能
客户设置的限制（并非所有客户都支持所有可用技术。在逐步替换旧系统或将新系统引入环境时，您当然应该考虑到这一点）
法律规定的限制

希望对你有所帮助。

【讨论】：

【解决方案3】：

我认为在您的原始帖子和 norbertB 的补充之间，您几乎涵盖了所有内容。从绝对约束开始（请记住，仅仅因为客户对某事说不一次——即使他们说这是绝对的——这并不意味着你不能帮助改变他们的想法......）。使用绝对约束缩小范围后，请查看其他内容。

似乎被忽略的一件事是灵活性。例如，如果我试图在两种相似的技术之间进行选择，并且我知道一种可以支持可更新视图而另一种不能，即使当时我完全不需要可更新视图，我仍然会倾向于那个“以防万一”。

【讨论】：

【解决方案4】：

我真的只想到两件事。首先是我是否会拥有如此多的数据以至于其他任何事情都很重要。如果您不将数百万行放入表中，那么您将使用哪种技术可能并不重要，因为它们的运行速度都足够快。

第二个问题是我能不能用LINQ，因为我发现用LINQ（to SQL，to Entities，to LLBLGen，没关系）查询数据库给了你两个重要的东西。第一个是编写查询非常容易，第二个是在需要 LINQ 的两个框架之间切换相当容易，以防需求发生变化。

【讨论】：