问题标签 [data-access-layer]

所以，我正在开发这个基于存储库模型的基于 Web 的应用程序，一个想要的 DDD 傻瓜，使用 StructureMap....等等等等。

该应用程序的一方面允许用户上传和管理文件。

应该在哪里、哪一层负责管理这些用户文件的保存/删除？

业务层，还是数据访问层……？

无论出于何种原因，它似乎都不是一个直截了当的答案......

从历史上看，我只是在 GUI 中打了它一巴掌，但努力使程序更正确，并重新思考应该处理这些服务的内容。也许我只是回答了我自己的问题......

我们正在研究使用 ORM，我想要一些意见/比较

我们对 ORM 的基本标准是：易于使用/配置（学习曲线短）、灵活、能够将其抽象出来、易于维护

这是我们正在查看的 ORM 以及我们的初步印象的列表

1. 开放存取——对于简单的东西来说似乎真的很容易，但似乎没有很大的灵活性，成本不是我们已经拥有的问题
2. Ling to SQL - 使用和配置看起来非常简单，但缺少一些功能
3. Active Record - NHibernate 变得简单
4. SubSonic - 看起来功能非常丰富，但并没有真正玩过它

这是我们查看并排除的 ORM

1. 实体仍处于测试阶段
2. NHibernate 有很长的学习曲线（我们没有 3 周的时间来学习它）

似乎许多 ORM 工具和自定义数据访问层（DAO 模式等）的目标是将数据库抽象到可以用最少的工作换出整个数据库系统的程度。

在代码中遵循常见的 DAL 模式通常是一个好主意，但换出数据库似乎永远不会是最小的工作。（成本、培训、数据迁移等）

有没有人有在大型系统中将一个数据库换成另一个数据库并处理代码中的影响的经验？是否值得担心从代码中抽象出实际的数据库？

我可能会负责将 vb6 应用程序移植到 c#。此应用程序是一个与访问数据库交互的 Windows 应用程序。数据访问被封装在基本业务对象中。基本上一桌一课。现有的 vb6 业务对象通过 DAO 读取和写入 DB。我之前写过几次 DAL 和 ORM，但它们都只针对 SQL Server。这将需要针对访问和 sql server。在之前的项目中，我会将 SQL 字符串放在业务对象的私有部分中，并且可能会将多余的 sql 代码（如连接、创建命令）移到公共基类中以减少代码。

这一次，我正在考虑将 SQL 字符串写入 .settings 文件或其他键/值类型的文本文件。然后我会编写一个 sql 实用程序来编辑这个文件并允许我运行和测试参数化查询。这些查询将在业务对象中按名称引用，而不是将 sql 嵌入代码中。

我知道一种标准方法是为每个目标数据库创建一个 DAL，并具有要使用的 DAL 的配置状态。我真的不想为每个数据库创建两个 DAL 类。如果我只是通过键名引用正确的查询并具有正确的连接类型，那么代码似乎会更少。

那么，你们是在做这样的事情吗？您将如何或曾经如何解决这个问题？什么最适合你？

谢谢！

我们正在尝试使用 WCF 和 ICriteria 创建一个很酷的 API，例如：

我们正在考虑使用 DetachedCriteria，以便任何人都可以发送它，我们将它连接到服务中的会话，以便在我们的数据库前面运行查询。

有没有人创建这样的 API？我们应该使用 Nhibernate 的 ICriteria 吗？还有其他很酷的想法吗？

谢谢。

这些术语通常可以互换使用，并且显然存在相当大的重叠，但似乎暗示人们经常看到通过说系统是 ORM 而不是因为它是 DAL 而暗示的东西。那是什么？如果有的话，区分这些类型系统的关键点是什么？

例如，假设我有一些代码实现了 Database、Table、Column 和 Row 类，通过对现有数据库的自动分析来填充它们，允许简化交互等等。它理解、执行和利用数据库实体之间的结构关系，例如外键。所有实体模型都可以进行子类化，以将特定于表的功能加载到它们上。

这在多大程度上是 DAL？它在多大程度上是一个 ORM？为什么？

我需要设计一个数据访问层 DAL .Net 企业库版本 3.5 数据访问应用程序块 (DAAB) 在我的应用程序中，我有各种逻辑模块，如注册、计费、订单管理、用户管理等我使用 C# 业务实体来将模块对象映射到数据库表，然后将 List 集合返回给客户端。

我想以这样一种方式设计我的 DAL，如果明天我们决定使用其他一些数据访问框架，我们应该对代码进行最少的更改。鉴于此，我如何设计我的班级结构？我以为我会有一个 DbManagerBase 类，它将是现有 .net DAAB 的包装器。此类 DbManagerBase 将实现一个名为 IDbManagerBase 的接口，该接口将具有 ExecuteReader、ExecuteNonQuery 等公共方法。

客户端类，即。RegistrationDAL,UserManagermentDAL 在其每个方法中都会包含以下代码： IDbManagerBase obj= new DbManagerBase() obj.ExecuteReader(myStoredProcName) 。. . 这是一个好的 OOPS 设计吗？请问我有什么更好的方法吗？或者我需要在这里使用继承吗？我可以将 DbManagerBase 类和 RegistrationDAL、UserManagermentDAL 类中的所有方法都设为静态吗？我想，如果我将方法设为静态，那么上面的接口代码将没有任何意义……对吗？？？

索引器的扩展方法，它们会好吗？

我正在玩一些重新水合 POCO 的代码。

代码围绕从 SqlDataReader 返回的行进行迭代，并使用反射从列值中分配属性。在我的调用堆栈中，我有一个这样的代码：-

Set 方法被编写为扩展方法。

能写出这样的代码就好了

即我想为索引器写一个扩展方法

.Net 没有索引器的扩展方法有充分的理由吗？其他人对扩展方法索引器有其他好的用途吗？

顺便说一句……如果我们可以为索引器编写扩展方法，那么我们可以编写这样的代码……</p>

我的代码中的一些片段

我已经要求使用单例模式实现的 DAL，但我认为很难汇集连接，使用事务..等等

我想知道利弊，也想知道连接连接的最佳方式，因为我正在开发的站点可能有超过 500 个并发用户。

数据库服务器是 Oracle 10g。

DAL 使用 Enterprise library 3.1

I'm using .Net enterprise library data access application block for my Data Access layer design.

In my Category DAL class, I've methods like :

GetProductsInCategory(int CatId), GetAllProducts, GetCategories, etc.

My question is: where do I put this line of code ?

shall I put it in every method above or shall I have a base class which would return Database object to my DAL class.

Also, shall I keep these DAL class methods as static?