database - 数据访问代码代表了你的代码库的百分之几？

Question

今晚推特上出现了一个有趣的问题，我觉得我会在这里发布。

基本上，我想知道您使用什么来将数据持久化到数据库中，以及估计代码库中数据访问代码的百分比。

-- 编辑 --
其他有趣的指标（如评论中所述）包括业务类的数量和代码库的总体大小。

我只是看了一个我在发现 NHibernate 之前做了很长时间的项目。快速查看一些数据访问代码，可以看到大约 10 行代码用于类中每个可持久属性的持久性/水合。

Answer 1

在我们做的一个项目中，我们使用 LLBLGenPro 作为我们的 OR/M。但是因为我们不想在我们的应用程序中乱扔 LLBL 实体，所以我们在它们到达客户端之前将它们映射到我们的 BO。这意味着在再次访问数据库之前将它们映射回 LLBL 实体。DAL 代码最终成为我们应用程序的很大一部分。不是 50%，但相当大。

在我现在正在处理的一个项目中，我从 db40 开始，希望最大限度地减少 DAL 占用空间。而且它很小，但我遇到了db40的问题，不得不放弃它。我切换到 ADO.NET 几天只是为了让一些东西正常工作，并且惊讶于我为了让一个简单的存储库工作而必须编写多少该死的 ADO。那是一个令人头疼的问题，所以我最终选择了 NHibernate。

我的 NHibernate (2.0) 的 DAL 代码可能占我代码库的 5% 或更少。这包括 XML 映射文件。我的意思是，DAL 的足迹是如此之小，与它一起工作非常愉快。过去，我在需要处理分离对象的分布式环境中遇到了 NHibernate 1.2 的问题，但 NHibernate 2.0 似乎已经解决了这个问题。我知道这是我从现在开始做 DAL 的方式，直到出现更好的东西。

有趣的是，几个月前我和我的同事进行了类似的对话。但我们的重点不是我们的 DAL 占了多少代码，而是我们的应用程序有多少只是简单的数据查询/操作。我们估计，我们应用程序的 90% 可能只是获取正确的数据子集并允许用户对其进行编辑。

Answer 2

我们大部分时间都使用 nHibernate，它是由一个工具生成的，不知道这是否重要，我们最终仍然会为每个实体向 nHibernate 层添加大量代码，是的；它确实继续成为代码的很大一部分。

此外，随着您在应用程序中添加更多功能和更多实体，DAL 代码也会增加。所以或多或少我猜大约 20%-30% 的代码库是由 DAL 组成的。