具有持久性的共享对象库

Posted 2023-04-01

【中文标题】具有持久性的共享对象库

【英文标题】：Shared Object Library with Persistence

【发布时间】：2010-06-23 19:51:48

【问题描述】：

我有一个简短的问题，我希望很容易回答。我正在尝试为我的公司开发一个共享的员工对象库。我们的想法是创建一个集中的数据库，其中包含有关我们员工的信息（报告层次结构、办公地点、一般信息等），然后为该数据库创建一个共享对象库。

我的问题是创建这个库以便在应用程序之间共享它的最佳方式是什么。

我是否创建了一个自包含库来存储数据库连接（我可以在此处看到并发问题，但感觉不对）。 客户端 -> 服务器，然后部署“客户端库”以在任何应用程序中使用。 或者，Web/WCF 服务是否更适合这种情况。

【问题讨论】：

库是指访问员工数据的类库还是数据库中的库？

我的意思是可以由任何应用程序实现以访问员工数据的类库。

【参考方案1】：

有很多选择，因为问题可以广泛翻译。我建议牢记所有答案。话虽如此，这是我对它的看法......

由于 n 层培训，我过去常常将软件层视为垂直的，并且很难摆脱这些概念，从而在概念上更广泛且限制更少。我努力将 .NET 组合视为拼图的一部分。

您将连接字符串与代码分开是对的，这很容易被 .NET .config 文件或应用程序设置支持。

我通常更喜欢包含业务逻辑、概念和流程的小型核心库，尽管其中每一个都可以分解。在这个概念中，您仍然可以将业务从数据访问中拆分为不同的程序集，以交换一种新的数据访问。但坚持使用核心模块（一种“业务内核”或“引擎”，如果你愿意的话）。

您可以通过多种演示类型来表达您的“业务内核”，例如

文本/控制台 I-O GUI：WinForms、WPF、Silverlight、ASP.NET、LED/pixelboard 等 作为 Powershell 交互的 cmdlet Web 服务表达式 各类移动应用 等

您可以使用模式来加速开发，使软件符合您的意愿和相关实现，例如：Microsoft Enterprise Library，通过依赖注入来放松耦合，例如Ninject（众多之一），或inversion of control 技术等。

【参考方案2】：

我通常更喜欢有一个中间层（因此在客户端和数据库之间有某种 Web/WCF 服务）。通过这种方式，您可以将客户端与数据库分开，以便您可以控制连接数，或者您可以以对客户端透明的方式更改数据库的架构。

根据您的情况，您可以让客户端连接到 WCF 服务（大多数情况下首选），或者创建一个 dll 来包装与服务的连接并在客户端执行一些额外的处理。

【参考方案3】：

这取决于您需要将库集成到主应用程序的深度。如果您想使用自定义实体扩展应用程序域，您有以下选择：

库中内置持久性。您需要将连接字符串传递给存储库类，而且数据库必须包含库的硬编码方案。如果您使用 LINQ to SQL 作为数据访问库，您可以使用映射属性标记您的实体（请参阅http://msdn.microsoft.com/en-us/library/system.data.linq.mapping.aspx） 仅提供域库，但在外部实现持久性，前提是您的数据层支持 POCO 映射（EF 4 支持）。

通常，将域模型放入单独的程序集中会导致一些问题：

集成到应用程序中。应用程序本身通常提供的服务很少，例如数据访问、安全性、日志记录、Web 服务等。如果您的应用程序具有理想的设计并且层之间完全解耦，则添加新实体没有问题，但通常数据访问层需要继承自基类，记录器是单例的，安全检查被硬编码到业务逻辑方法等。这样的应用程序必须被重构，服务必须被提取到接口中，并且这些接口必须被传递给单独的组件中的组件。

实体引用。如果您使用富域模型，您可能希望引用在另一个程序集中声明的实体。部分这个问题可以通过泛型解决，但是您需要对数据访问层进行特殊设计，以允许您获取泛型实体列表，或通过 id 获取实体等。

数据库集成。如果某些实体与其他实体分开开发，尤其是由其他团队开发，则可能很难维护数据库更改。

【参考方案4】：

请确保将连接方法与数据访问层分开，然后如果需求发生变化，您可以稍后更改连接方法。如果你有一个简单的 DLL 来保存你的真实逻辑，那么在上面添加一个通信层应该很简单。这也将允许您使用您提到的所有三种方法，并将所有实际逻辑放在一个 DLL 中，用于所有三种方法。