我正在为各种内部 CRUD 应用程序开发一个框架。我已经考虑了几种 MS 技术（WPF、Access、WinForms、ASP.NET），并且已经为客户端选择了带有 HTA+Jquery 的 ASP.NET MVC。我这样做的原因是，我需要一种方法来编写和部署快速的一次性 GUI 应用程序，以及维护预计具有较长生命周期的更强大的应用程序。
首先，对于在客户端使用 ADODB 与在服务器端使用 ADO.NET 的相对优点，我将不胜感激。我倾向于 ADODB，因为我将拥有对 SQL Server 的客户端访问权限（我已经编写了一个处理与 ADODB 交互的 js 库）。但是，我可以看到开发 RESTful 服务最终可能会有用。
其次，我需要将报告功能整合到系统中。我可以使用 SQL Server 报表服务或水晶报表，但用户已经习惯了一些使用 VBA 在 Word 中编写报表的旧应用程序；所以我正在考虑使用 WordML 来编写报告。
谢谢。
数据库访问
如果您需要一个瘦客户端，那么最好不要从客户端直接访问数据库。
主要问题是您将引入对特定网络架构的高度依赖，并且您的 ASP.Net 应用程序和 HTA 都将高度依赖数据库。
相反，我更愿意切断对数据库的直接视线的依赖，并让数据由服务器处理。
这有几个优点：
对于数据库的许多小的更改，您可能只需要更新 ASP 应用程序。
如果您需要您的客户端应用程序在 Internet 上运行（例如，因为一些用户要参加外部会议、需要下班或您的公司开设新分支机构），那么您将不必重写您的瘦客户端。
您可以更好地控制对资源的访问：只让 ASP 应用程序与数据库对话并过滤输入/输出的内容。
这将使您不必在客户端实现所有安全性：ASP 应用程序成为数据库的守护者。这是一种更好的保护信息的方法，它为您提供了更多的控制权。
报告
对于报告，我会再次使用服务器，而不是在客户端本身实现复杂的报告功能。
问题是，如果您使用 HTA 并且不想开始在每个用户的机器上安装依赖项，那么您将始终受到客户端的限制。
你很快就会建立一个胖客户端......
如果您使用的是 ASP.Net，那么有很多非常好的报告工具可以让您的生活更轻松，并允许您的用户在 Excel、Word、PDF 等中获得漂亮的报告，而无需您自己编写这些功能。
Crystal Reports 没问题，但还有更好更简单的替代方案，例如Developer Express Report引擎非常易于使用。