具有持久性的共享对象库
我有一个简单的问题，我希望这个问题很容易回答。我正在尝试为我的公司开发一个共享的员工对象库。我们的想法是创建一个集中数据库，其中包含有关我们员工的信息（报告层次结构、办公地点、一般信息等），然后为此数据库创建一个共享对象库。
我的问题是创建这个库的最佳方法是什么，以便它可以在应用程序之间共享。
- 我是否创建一个存储数据库连接的自包含库（我可以在这里看到并发问题，但感觉不对）。
- 客户端->服务器然后部署“客户端库”以供任何应用程序使用。
- 或者 Web/WCF 服务更适合这种情况。
I have a quick question that I am hoping is fairly simple to answer. I am attempting to develop a shared Employee object library for my company. The idea is to create a centralized database that contains information about our employees (Reporting Hierarchy, Office Locations, General Info, etc) and then create an shared object library for this database.
My question is what is the best way to create this library so it can be shared among applications.
- Do I create a self contained library that stores the database connection (I can see concurrency issues here and it doesn't feel right).
- Client -> Server and then deploy the "client library" for use among any application.
- OR would a Web/WCF service be more ideally suited to this situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
有很多选择，因为这个问题可以广泛翻译。我建议牢记所有答案。话虽如此，这是我的看法……
由于 n 层训练，我过去常常将软件层视为垂直的，并且很难摆脱这些概念，转向概念上更广泛、限制更少的东西。我努力将 .NET 汇编视为拼图的一部分。
将连接字符串与代码分开是正确的，.NET .config 文件或应用程序设置很容易支持这一点。
我通常更喜欢一个具有业务逻辑、概念和流程的小型核心库，尽管其中每一个都可以被分解。在这个概念中，您仍然可以将数据访问业务分解为不同的程序集，以交换新类型的数据访问。但坚持使用核心模块（一种“业务内核”或“引擎”，如果你愿意的话）。
您可以通过许多演示类型来表达您的“业务核心”，例如
的 cmdlet。您可以使用模式加速开发，使软件符合您的意愿和相关实现，例如：Microsoft Enterprise Library，放宽与依赖注入耦合，例如 Ninject （众多之一），或 控制反转技术等
There are many options because the question can be translated broadly. I suggest taking to heart all answers. Having said that here's my spin on it...
I used to view software layers as vertical because of n-tier training, and have a hard time breaking away from those notions to something conceptually broader and less restrictive. I strive to view .NET assembles as just pieces of a puzzle.
You're right to separate connection string from code and that's easily supported by .NET .config file, or application settings.
I often prefer a small, core library having the business logic, concepts and flows although each of those can be broken out. And within that concept you can still break out business from data access as different assemblies to swap in a new kind of data access. But sticking with the core module (a kind of "business kernel" or "engine" if you will).
You can express your "business kernel" through many presentation types, for example
You can accelerate development using patterns to bend software to your will and related implementations like: Microsoft Enterprise Library, loosen the coupling with dependency injection e.g. Ninject (one of many), or inversion of control techniques, etc.
我通常更喜欢有一个中间层（因此客户端和数据库之间有某种 Web/WCF 服务）。通过这种方式，您可以将客户端与数据库分开，以便您可以控制连接数，或者可以以对客户端透明的方式更改数据库的架构。
根据您的情况，您可以让客户端连接到 WCF 服务（在大多数情况下首选），或者创建一个 dll 来包装与服务的连接并在客户端执行一些附加处理。
I usually prefer to have a middle tier layer (so some sort of Web/WCF service between the client and the database). This way you separate the clients from the database, so that you can control the number of connections, or you can change the schema of the database in a way that will be transparent for the clients.
Depending on your situation, you can either make the clients connect to the WCF service (preferred in most cases), or create a dll that will wrap the connection to the service and perform some additional processing on the client side.
这取决于您需要将库集成到主应用程序中的深度。如果您想使用自定义实体扩展应用程序域，您有以下选择：
通常，将域模型放入单独的程序集中会导致很少的问题：
集成到应用程序中。应用程序本身通常提供很少的服务，例如数据访问、安全、日志记录、Web 服务等。如果您的应用程序具有理想的设计并且各层之间完全解耦，则添加新实体没有问题，但通常数据访问层需要继承基类，记录器是单例的，安全检查被硬编码到业务逻辑方法中等等。这样的应用程序必须重构，服务必须提取到接口中，并且这些接口必须传递给分离组件中的组件。
实体引用。如果您使用富域模型，您可能想要引用在另一个程序集中声明的实体。这个问题可以部分地通过泛型解决，但是您需要对数据访问层进行特殊设计，以允许您获取泛型实体列表，或通过 id 等获取实体。
数据库集成。如果某些实体与其他实体分开开发，特别是由其他团队开发，则可能很难维护数据库更改。
It depends how deep you need to integrate you library into main application. If you want to extend application domain with custom entities, you have following options:
Usually, putting domain model into separated assembly causes few problems:
Integration into application. Application itself usually provides few services, like data access, security, logging, web services etc. If your application have ideal design and layers fully decoupled from each other, there is no problem to add new entities, but usually data access layer requires inheritance from base class, logger is singleton, security checks are hardcoded into business logic methods etc. Such applications must be refactored, services must be extracted into interfaces, and such interfaces must be passed to components in separated assembly.
Entity references. If you use rich domain model, you probably want to reference entities declared in another assembly . Partially this problem can be solved by generics, but you need to have special design of your data access layer that allows you to get lists of generic entities, or get entity by id etc.
Database integration. It may be hard to maintain database changes, if some entities are developed separately from others, espesially by other team.
只需确保将连接方法与数据访问层分开，然后如果需求发生变化，您可以稍后更改连接方法。如果您有一个简单的 DLL 来保存您的实际逻辑，那么在顶部添加一个通信层应该很简单。这还允许您使用您提到的所有三种方法，并将所有实际逻辑放在所有三种方法中使用的单个 DLL 中。
Just be sure to keep your connection method separate from your data access layer, and then you can change the connection method later if requirements change. If you have a simple DLL that holds your real logic, then adding a communication layer on top should be simple. This will also allow you to use all three methods you mentioned and have all your actual logic in a single DLL used amongst all three.