任何与MS-Access一起使用的ORM（用于原型设计）？

Question

我处于项目的早期阶段，目前尚不清楚我们是否需要一个“真正的”数据库（即SQL Server等）。所以我一直在使用MS-Access做一些原型设计，到目前为止工作正常。 （在C＃/ VS2008 / .Net 3.5 / MS-Access 2000中开发）。

然而，物体 - 关系阻抗不匹配已经变得烦人，并且随着项目的发展而变得更糟。

我无法找到适用于MS-Access的ORM。有什么建议吗？

修改 - 跟进 我们最终使用Fluent NHibernate，主要是因为它将我们的对象模型自动化到关系数据库，这对我们来说是一个巨大的胜利。我们发现的大多数FNH代码示例都使用了SQLite，这非常有效，我们打算将它用于我们的生产数据库。 （该应用程序是一个桌面科学数据收集和分析包）。

Answer 1

MSAccess文件可以在Windows计算机上设置为ODBC源。几乎任何ORM都允许您使用ODBC。 Here是一个关于如何设置它的快速教程，它是为Win2k概述的，但XP +的过程是相同的。您还需要在包装盒上安装MDAC。

NHibernate似乎也支持MSAccess，请参阅here。我从来没用过它。它还有一个ODBC driver.。许多其他人也支持ODBC。

同样，正如其他人所说的那样...... MSAccess无法扩展...... 期间。安装一个真正的数据库服务器相当容易，因此我建议使用SQL Server Express，就像其他人一样，甚至是MySQL或Postgre，这些更容易设置。

如果这是您打算部署到客户端的应用程序，每个客户端都有自己唯一的数据库，我会完全推荐另一种解决方案SQLite。 SQLite以应用为基础为您提供应用程序的数据库功能。如果您有一个中央数据库服务器，那么前面提到的解决方案之一就是最好的。

Answer 2

无法回答您的问题，但您可能需要考虑以下选项之一，而不是Access：

• SQL Server Express：免费且与完整的SQL Server兼容
• SQL Server Compact：也是免费的，不需要任何部署/安装，不支持所有功能（例如没有存储过程）。

Answer 3

选择Access数据库引擎是一个不错的选择：使用Access Forms构建一个自包含的Access应用程序时（虽然首先选择使用Access是一个值得怀疑的选择;）

VS2008最适合的数据库引擎是SQL Server，你可以毫无困难地找到一个与SQL Server兼容的ORM。

Answer 4

在这个阶段，如果你不确定你是否需要一个“真正的”数据库，我会跳过MS Access并直接进入sql server express。它是免费的，仍然可以让你做你需要的一切。

另外，如果您以后决定需要扩大规模，那么您可以毫不费力地使用。

Answer 5

我建议您使用Microsoft SQL Server或PostgreSQL之类的东西进行原型设计。如果您不想学习特定的SQL语法并安装用于设计数据库模式的特殊工具，则可以使用ORM从持久类声明中自动生成数据库模式。无论如何，这种方法对于原型设计非常有效。

Answer 6

LLBLGen适用于Access

Answer 7

访问只是一个坏主意。我相信MS只包含Access in Office以保持传统用户满意。

即使您发现一个可以与Access数据库一起使用的ORM，除了少数例外，您将自己锁定在一个利基工具中，该工具可能无法与真正的数据库引擎一起使用。如果您决定稍后切换到真正的数据库引擎，您不仅需要处理迁移数据库，还需要切换到其他ORM。

See this comparison between SQL Server Express and SQL Server Compact。比较文档还提到了其他数据存储的一些问题，包括Access。

如果您真的担心能够安装SQL Server Express，请考虑使用SQL Server Compact：

• 它可以链接到您的可再发行应用程序。无需安装服务（在安装应用程序时可能需要管理员权限）;安装应用程序时，一切都会得到妥善处理。如果您需要将数据驻留在用户的计算机而不是服务器上，这是最有意义的，并且最类似于使用Access。

• 它的功能不如Express（不支持视图，触发器，存储过程，我认为是必需的）

• 可以非常容易地扩展到Express或其他SQL Server版本

• 适用于平板电脑，移动设备等小型安装

在设计任何应用程序时始终牢记可扩展性。如果/当你的应用程序因为你选择了错误的工具而成功获得成功时，你不想编写PHP-＆gt; C ++编译器。

我们正在努力：

Access的大问题（或者，在这种情况下，Jet引擎，这是将Access数据库与.NET应用程序集成时真正使用的部分）是没有“服务器”处理数据请求。托管在您的应用程序中的引擎必须直接读取和写入包含数据库的磁盘上的文件。每当发生这种情况时，必须锁定该文件以防止并发写入。随着用户数量的增长，脏读取变得越来越普遍，数据库损坏的可能性也越来越大。

想象一下，让一家大餐馆的每位顾客都试图同时进入厨房写下订单或取回食物。会导致混乱。会有很多破碎的菜肴，厨房会很乱，你很幸运能得到你在任何食物条件下订购的东西。有一个客户，这可能工作正常。 5，呃，也许吧。有20,50,1000？没那么多。

因此，餐饮业引入了服务员和管理人员，将IO缓冲到厨房。数据库服务器应用程序通过限制对磁盘上文件的访问来执行大致类似的操作。每个人都能以更可靠的方式获得他们想要的东西，并且数据存储受到保护。