我们正在构建一个企业应用程序，我们将在其中整合多个用户界面平台（即 ASP.net webapp、Windows 应用程序，以及未来的移动应用程序）和多个后端数据库平台（即 SQL Server、XML、Oracle）。另一个必要条件是这些后端数据库要么集中并通过 Web 访问，要么本地化在客户端计算机上，偶尔同步到中央服务器。
任何人都可以就我们如何抽象用户界面层和数据层提供建议，以便我们可以更简单地在各种 UI 和 DB 的各种选择之间创建即插即用的适应性？例如：在一种情况下，我们可能有一个通过互联网在中央服务器上运行的网络应用程序，我们可能有远程机器通过一个 Windows 应用程序运行本地化副本。在预定的时间间隔内，我们希望所有机器同步，以便它们都可以拥有近乎实时的数据。
我们还需要有关处理所涉及的各种连接字符串的建议，以便在任何一个应用程序上需要更改的唯一设置是“本地”或“远程”，然后它们将确定必要的连接字符串。
一旦掌握了 n 层架构的窍门，抽象表示层是一个相当简单的概念。只需专注于区分“领域逻辑”和“应用程序逻辑”。域逻辑在您的不同平台上是通用的，而应用程序逻辑是特定于平台的。例如，数据验证是域逻辑（虽然你可以在前端执行它很好，这会使事情变得更复杂，但在这里和我一起工作......）并决定在某些操作后重定向到哪个 URL 是应用程序逻辑。确保将域逻辑放在任何平台都可以使用的级别，并确保不要将任何应用程序逻辑放在域层中。
您问题的另一半似乎是您更大的焦点，但我想在这里要求澄清一下，因为我可以辨别出两个不同的基本问题。
我希望您不要追求数据库独立性的“圣杯”。在设计阶段，这始终是一个崇高的目标，几乎总是，几乎每次都不需要。
如果这不是您想要的，那么我建议您应该知道哪些对象存储在哪个持久性介质中，并且您应该避免灵活性的复杂性，并以直接的方式编码您的垂直路径尽可能。IE 不会将额外的东西编码到将其数据存储在 Oracle 中的某些业务类中，以使您能够“在将来的某个时间”将其放入 SQL Server。（我循环回到数据库独立性，不是吗？）
在本地缓存数据以提高某些平台的性能的问题特定于这些平台，我建议您查看智能客户端和 MS P&P 团队拥有的缓存框架/指导。在过去的几年里，我一直非常专注于网络方面的工作，但在 05/06 的时候情况非常好，与此同时，他们在智能客户端方面也做了很多工作。
我会考虑使用提供者模型在您的应用程序中建立数据库连接。
我将首先查看 Microsoft 数据应用程序块中提供的示例和详细信息，我认为这将有助于您实现目标。