当底层数据库存在关系时，系统使用来自另一个系统的 WCF 服务
这是我在许多系统中都遇到过的一个问题，但这个就是一个很好的例子。它与一个系统使用另一个系统的WCF服务有关，每个系统都有自己的数据库，但两个数据库之间存在关系。
我们有一个中央数据库，保存公司所有文件的记录。该数据库包括文档和文件夹表，它模仿 Windows 文件结构。 NHibernate 负责数据访问，域层处理逻辑（验证文件名/同一文件夹中没有相同的文件名等），服务层位于其上，服务名为“CreateDocument(bytes[])”、“RenameDocument(id)” , newName) ', 'SearchDocuments(filename, filesize,createdDate)' 等。这些服务通过 WCF 公开。
人力资源系统使用这些服务。 HR 数据库有一个单独的数据库，该数据库具有文档数据库的外键：它包含一个 HRDocument 表，该表具有外键 DocumentId，然后是 HR 特定的表，例如 EmployeeId 和 ContractId。
以下是其他问题：
1）为了保存文档，我必须调用 WCF 服务将其保存到中央数据库，返回 ID，然后保存到 HRDocument 表（以及 HR 特定信息）。由于 WCF 调用和所有特定于文档的数据访问都是在文档应用程序内完成的，因此无法在一个事务中完成所有这些操作，从而可能导致事务完整性丢失。
2）为了搜索employeeId和createdDate，我必须调用传入createdDate（文档数据库特定字段）的搜索服务，然后根据返回记录的Id搜索HRDocument数据库以过滤返回的结果。这感觉很混乱、缓慢而且是错误的。
我可以将 NHibernate 映射文件复制到 HR 应用程序 DAL 中的文档数据库。这意味着我可以指定 HRDocument 和 Document 之间的关系。这意味着我可以像这样连接表和搜索，但也意味着我必须重复域逻辑并违反 DRY 原则，以及所有这些。
我不禁觉得我在这里做错了什么并且错过了一些简单的事情。
This is an issue that I have struggled with in a number of systems but this one is a good example. It is to do with when one system consumes WCF services from another system, and each system has their own database, but there are relationships between the two databases.
We have a central database that holds a record of all documents in the company. This database includes Document and Folder tables and it mimicks a windows file structure. NHibernate takes care of data access, a domain layer handles logic (validating filenames/no identical filenames in the same folder etc.) and a service layer sits on that, with services named 'CreateDocument(bytes[])', 'RenameDocument(id, newName) ', 'SearchDocuments(filename, filesize, createdDate)' etc. These services are exposed with WCF.
An HR system consumes these services. The HR database has a separate database that has foreign keys to the Document database: it contains an HRDocument table that has a foreign key DocumentId, and then HR specific such as EmployeeId and ContractId.
Here are the problems amonst others:
1) In order to save a document, I have to call the WCF service to save it to the central db, return the ID and then save to the HRDocument table (along with the HR specific information). Because of the WCF call and all Document specific data access being done within the Document application, this can't be done all within one transaction, resulting in a possible loss of transaction integrity.
2) In order to search on say, employeeId and createdDate, I have to call the search service passing in the createdDate (Document database specific fields) and then search the HRDocument database on the Id's of the returned records to filter the results returned. This feels messy, slow and just wrong.
I could duplicate the NHibernate mapping files to the Document database in the DAL of the HR application. This means I could specify the relationship between HRDocument and Document. This means I could join the tables and search like that but would also mean I would have to duplicate domain logic and violate the DRY principle, and all that entails.
I can't help feeling I'm doing something wrong here and have missed something simple.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议您在此处应用 CQRS 和事件驱动架构原则
将能够生成主键
获取文档并将其传递给 WCF
方法调用。
（如果数据库出现故障并且
类似的东西）。
一致应用程序不
规模。使用最终一致性
相反，范式。
引入单独的数据存储
读取包含非规范化数据的目的。然后你将能够
进行搜索非常容易。为确保
读取存储的一致性（在
创建
文档时的情况失败）你可以实施一些
简单的工作流程（
I recommend you to apply CQRS and Event Driven Architecture principles here
will be able to generate primary key
for document and pass it to WCF
method call.
(in case of database failure and
something like that).
consistent applications don't
scale. Use eventual consistency
paradigm instead.
Introduce separate data storage for
reads purpose that contains denormalized data. Then you will be able
to do search very easy. To ensure
consistency in your read storage (in
case when
Documentcreationfailed) you could implement some
simple workflow (saga in terms of
CQRS)
您可以创建一个通用代码库，其中包括文档的基本实现以及所有映射、基本域模型等。
文档服务和 HR 系统使用相同的代码库。但在 HR 系统中，您可以使用继承映射策略使用 HRDocument 扩展基文档类（或多个类），这将最适合您的需求。
从 HR 系统中，您甚至不必再调用文档服务，您只需使用 NH 并享受 ACID 等。但文档服务仍然存在，并且没有代码重复。
You can create a common codebase which will include base implementation of Document along with all the mappings, base Domain Model etc.
A Document Service and an HR System use the same codebase. But in HR System you extend base Document class (or classes) with your HRDocument using inheritance mapping strategy which will suit your needs the best.
And from HR System you don't even have to call Document Service anymore, you just use NH and enjoy ACID and all that. But Document Service is still there and there's no code duplication.