我有一个简短的问题，我希望回答相当简单。我正在尝试为我的公司开发一个共享的Employee对象库。我们的想法是创建一个集中式数据库，其中包含有关我们员工的信息（报告层次结构，Office位置，常规信息等），然后为该数据库创建共享对象库。
我的问题是创建此库的最佳方法是什么，以便可以在应用程序之间共享。
答案 0 :(得分：1)
我通常更喜欢拥有中间层（因此客户端和数据库之间存在某种Web / WCF服务）。这样，您可以将客户端与数据库分开，以便可以控制连接数，也可以以对客户端透明的方式更改数据库的架构。
根据您的具体情况，您可以让客户端连接到WCF服务（在大多数情况下是首选），或者创建一个dll，它将连接到服务并在客户端执行一些额外的处理。
答案 1 :(得分：1)
这取决于您将库集成到主应用程序中需要多深。如果要使用自定义实体扩展应用程序域，可以使用以下选项：
通常，将域模型放入单独的程序集中会导致很少的问题：
集成到应用程序中。应用程序本身通常提供的服务很少，如数据访问，安全性，日志记录，Web服务等。如果您的应用程序具有理想的设计并且层完全相互分离，则添加新实体没有问题，但通常数据访问层需要继承自基类，记录器是单例，安全检查是硬编码到业务逻辑方法等。这些应用程序必须重构，服务必须提取到接口中，并且这些接口必须传递给分离汇编中的组件。
实体引用。如果使用富域模型，则可能需要引用在另一个程序集中声明的实体。部分这个问题可以通过泛型来解决，但是您需要对数据访问层进行特殊设计，以便获取通用实体列表，或者通过id获取实体等。
数据库集成。如果某些实体与其他实体分开开发，特别是其他团队，则可能很难维护数据库更改。
答案 2 :(得分：1)
有很多选择，因为这个问题可以广泛翻译。我建议把所有的答案放在心上。说过这是我的旋转...
由于n层培训，我过去常常将软件层视为垂直层，并且很难将这些概念从概念扩展到更广泛且更少限制的概念。我努力将.NET组合视为一个难题的一部分。
您可以将连接字符串与代码分开，并且.NET .config文件或应用程序设置可以轻松支持。
我经常更喜欢具有业务逻辑，概念和流程的小型核心库，尽管每个都可以分解。在这个概念中，您仍然可以将数据访问中的业务分解为不同的程序集，以交换新的数据访问。但坚持使用核心模块（如果你愿意，可以使用“商业内核”或“引擎”）。
您可以通过多种演示文稿类型表达“业务内核”，例如
您可以使用模式加速开发，以便根据您的意愿和相关实现来弯曲软件，例如：Microsoft Enterprise Library，放松与依赖注入的耦合，例如Ninject（众多之一），或inversion of control技术等。
答案 3 :(得分：0)
确保将您的连接方法与数据访问层分开，然后如果需求发生变化，您可以稍后更改连接方法。如果您有一个包含真实逻辑的简单DLL，那么在顶部添加通信层应该很简单。这也将允许您使用您提到的所有三种方法，并将所有实际逻辑都放在一个DLL中使用。