logo标签列表

使用MS Access作为.NET应用程序的后端

c#.netms-access
5

我是一家非IT组织中唯一的.NET开发人员。 我被要求使用Microsoft Access作为后端（现有数据库）开发.NET应用程序。

我不知道从哪里开始。

由于我是独自开发，开发过程中应该注意避免什么？ 独立开发者会面临哪些情况？

请在您的答案中包含Microsoft Access特定的建议，因为这与问题相关。

1
请重新表达标题来表达您的真正问题：如何为MS Access实现.NET应用程序。 - Stefan Steinegger
除了说OLEDB和ODBC应该可以对其进行操作之外，我在Access方面帮不上太多忙。我已经是一名孤独的.NET开发人员多年了。虽然没有束缚很好，但我的最佳建议是要对自己施加一些限制。对我来说，最大的改进是使用番茄工作法掌控我的时间管理。除此之外，我寻求问责：现在我每周向雇主报告我的具体活动。我发现这两个非技术性的进步对我的生产力都有很大的帮助。 - Joel Cochran
我担心那些最有Jet/ACE（Access开发人员）重要经验的人最不可能有.NET经验。而.NET开发人员可能很少接触Jet/ACE（因为它是为COM而非.NET构建的，这也是一个很好的理由）。如果你希望得到关于Jet/ACE的有用答案（而不是关于使用.NET开发数据库应用程序的好建议），你需要更具体一些。 - David-W-Fenton
在下面，您还通过说“它是一个专注于报告生成的小型应用程序”混淆了问题。您是指自动访问报告，还是通过.NET可用技术进行报告？ - David-W-Fenton
6个回答
13

从哪里开始？

  1. 选择一个开发环境（我建议根据预算和专业版所需的功能选择Visual Studio 2008 Express或Professional）
  2. 即使只有一个开发人员：选择版本控制系统！（Subversion管理开销较小，适用于单个开发人员）
  3. 选择一个.NET Framework版本（除非您的应用程序必须在Win2K上运行，否则3.5是可以的；对于Win2K，请使用.NET 2.0）
  4. 选择一种成熟的编程语言（C#或VB.NET，选择您或您的上司最喜欢的）
  5. 选择一个GUI技术（对于单个开发人员，我建议使用WinForms，除非您将编写Web应用程序或命令行实用程序）
  6. 选择一种成熟的DB访问技术（ADO.NET适用于许多事情，除非您具有更好的旧ADO / OleDB或DAO处理高性能要求）
  7. 编辑：使用Google查找一些与所选技术相对应的入门示例，或者购买一本书。例如，这里是使用OLE DB访问MS Access数据库的C#示例。 这个Access网站也是一个好的起点。
  8. EDIT2: 熟悉“Microsoft Access”（Office应用程序）。不是因为您将像典型用户一样使用它，而是您可能需要用它进行管理。即使您使用C#或VB.NET编程，其中包含的VBA和SQL文档有时也会很有帮助。

  9. EDIT3: 为了报告目的，选择一个报告技术。这里有很多可能性，取决于您的需求，技能和/或预算，例如

    • 手工编写的普通ASCII或CSV报告
    • HTML或XML报告
    • 使用Excel作为报表引擎
  • 使用像Report.NET这样的PDF库
  • 使用Crystal Reports等第三方工具

    • 当你在Google中搜索"report generation .net"时，你会找到很多有用的链接，例如这个。

    最后，当你遇到问题时，请回到SO并提出更具体的问题。

    根据组织中已有的代码可能会有其他限制。我建议避免使用像F#、WPF或Linq to Entities这样的技术。

    3
    他已经说过他是一名.Net开发人员，他不需要关于如何开始在.Net中进行开发的建议，他只想得到有关如何处理他目前保存在MS Access中的数据的建议。 - Chris Latta
    .NET是一个广泛的技术领域。在给定的限制条件下，我尝试提出一些建议，选择哪些.NET部分。 - Doc Brown
    如果你没有现有的数据库，我建议你创建一个信息模型。这项工作应该涉及你和商业端的人员，这样当你讨论功能、函数等内容时，你们使用的术语是相同的。这是减少误解的一种方法。 - magnus
    1
    这里有一个很好的答案，基本上是一个专注于报告生成的小应用程序。我想知道的是，在这种情况下是否有必要使用任何设计模式？ - Dhanapal
    @Doc Brown：“当然，ADO.NET可以处理Jet/ACE”（然后引用了关于OLEDB的文章）。据我所知，ADO.NET != OLEDB。经典的ADO是OLEDB的包装器，但我不知道ADO.NET是什么抽象层（我是一个Access程序员--我使用Jet/ACE本地化，没有数据访问层，除了它的本地DAO）。事实上，第二个引用说：“只有一个产品——SQL Server——受到ADO .NET托管提供程序的本机支持。”这似乎表明，通过ADO.NET使用Jet/ACE就像通过经典的ADO或DAO使用Jet/ACE一样——你正在使用COM而不是本地的.NET技术。 - David-W-Fenton
    显示剩余8条评论
    6
    你的问题过于模糊，我们只能提供一般性建议。如果你已经开发了其他 .Net 应用程序，那么开发这个新应用程序的方法应该并没有太大不同。
    数据库注意事项：
    当使用 MS Access 作为后端数据库时，需要注意以下几点：
    1. 可扩展性 - MS Access 的扩展性不太好，只适合少量用户使用。*编辑：用户数量取决于他们执行的活动类型 - 对于报告解决方案，Microsoft自己建议最多支持约100个并发用户 - 此white paper提供更多信息*
    2. 安全性 - MS Access 不提供与其他数据库产品（SQL Server、Oracle、MySQL）相同复杂的安全级别。
    3. SQL 语法 - 您编写某些类型的 MS Access 查询时存在一些细微差别。
    4. 其他限制 - MS Access 不支持存储过程，因此所有数据访问代码都必须使用内联 SQL 命令（command.Type = CommandType.Text）
      1. Microsoft Access 支持的最大数据库大小为2GB - 要注意数据库的增长

    设计考虑：

    1. 现有的MS Access数据库中是否已经存在一些用户表单和代码模块？如果是，您可以将其用作应用程序的基础 - MS Access使用Visual Basic for Applications（VBA）作为其编程语言，我不知道有任何工具/实用程序可以将VBA移植到VB.Net

    2. 是否存在类似的应用程序可以帮助您了解设计？

    3. 尽可能将数据访问代码从表单中分离出来 - 尝试将数据访问代码放在一个单独的类/DLL中，以便更容易维护

      • 编辑：正如其他人建议的那样，尽量避免在用户界面中散布ADO.Net连接和命令对象的实例 - 将所有数据库连接代码放在一个类/DLL中，以便更容易修复/维护/替换。出于同样的原因，我还建议将所有SQL查询语句放在单独的类或模块中。*

    4. 遵循您或之前其他人制定的内部指南。

    5. 考虑可维护性 - 之后的某个人可能需要进行更改。在代码中使用注释，并为您的对象（表单/变量/函数名称）赋予明智的名称

    6. 定期备份您的代码 - 每天将副本放在网络驱动器或USB驱动器上

    "MS Access 不太适合大规模使用，只适用于少量用户。" 请问这里的“少量用户”是指多少人？ - David-W-Fenton
    1
    "MS Access不支持存储过程": Access/Jet/ACE没有过程化代码，但它有其保存的QueryDefs，对于SELECT语句来说就像VIEWS，对于DML SQL来说就像存储过程（没有任何过程化代码）。因此，声称必须在代码中全部使用SQL是完全错误的。 - David-W-Fenton
    已编辑答案以提供更多细节。 - Jazza
    @David：当您要求“少量用户”时，为什么不将此链接https://dev59.com/1nRA5IYBdhLWcg3w9y10#766181发布到您已经给出的答案中呢？ - Doc Brown
    为什么不发布我的答案链接？因为我不记得所有的答案，即使我记得它们，我也不觉得在SO搜索中很容易找到它们！ - David-W-Fenton
    显示剩余4条评论
    4

    一个建议是将所有与Access相关的代码封装在一个类中。这个类至少应该能够:

    • 定位Access .mdb文件
    • 创建并打开所有OleDbConnection对象。
      • 非常重要的是，保证所有连接都能够关闭，因此在使用它们时将它们包含在using块中是一个很好的主意。
    • (可能)构建和执行所有OleDbCommands（从消费组件中删除特定于数据库的逻辑--它们应该能够进行数据请求和检索结果，同时透明地创建Connection & Command等）。
    0

    如果您已经熟悉.NET语言和MS Access，那么我的建议是先开发一个非常简单的MS Access数据库，并编写一个小的.NET控制台应用程序，连接到该数据库并执行一些基本功能，例如查询/插入/删除/更新。然后就可以逐步构建在这个基础上，引入GUIs/分离的库（dlls）等。

    不幸的是，对于您来说，.NET的Linq to SQL（ORM）不支持MS Access数据库，因此您将不得不从头开始开发业务对象（这并不总是坏事！）。

    这里有一个很好的起点使用C#的MS应用程序。

    0

    如果要访问Access数据库，您可以尝试使用NHibernate。据我所知，它支持Microsoft Access，如果您将数据移动到其他类型的数据库中，使用这样的库可能会使事情变得更加容易。

    如果任务是使用现有的数据库，那么Hibernate不会是我的首选，正如OP所需求一样。它可能会起作用，但这真的值得付出努力吗？ - Doc Brown
    嗯，我对NHibernate没有太多经验，但它看起来是一个很好的数据库抽象工具/ORM。如果你可以使用Linq进行查询（我已经读到应该是可能的），那么我会说这绝对是一件好事。不过，就个人偏好而言，我认为使用Linq to Entities可能更顺畅，从最新的PDC来看，它似乎非常流畅。（http://microsoftpdc.com/Sessions/FT10） - Svish
    我的意思是，“当您拥有一个不是专门为NHibernate设计的已经存在的数据库时，这样做真的值得吗？”顺便说一句，原帖作者添加了一条评论，他只想编写一个报告生成工具。 - Doc Brown
    我认为NHibernate和其他ORM工具（如Entity Framework）的关键之处正是你不需要专门为其设计数据库。无论如何，这只是一个建议:) 我目前正在一个项目上工作，我们使用Linq to SQL，并且数据库并非真正针对它进行设计。尽管如此，即使你给我报酬，我也不认为我会放弃Linq to SQL。至于报告，我们使用Microsoft Reporting Services。 - Svish
    @Svish：在这里找到了一个支持你的答案，可能会感兴趣：https://dev59.com/5kbRa4cB1Zd3GeqPykTD - Doc Brown
    0

    这里有很多好的建议，我想要补充的是一定要在一个明确定义的接口后面构建所有数据访问和修改类。我相信总会有这样的时候，当这个应用程序超出了 MS Access 的范围，拥有明确定义的接口将使升级到另一个数据库更容易。

    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接