EagerReadDerivation：平衡收益与成本
我正在为即将开发的 Silverlight 应用程序学习领域驱动设计和分布式 DDD。 EagerReadDerivation 模式似乎会提高应用程序的可扩展性，但代价是增加复杂性。
该应用程序可能有数千名用户上传需要由多个服务处理的大型文本文件（100,000 多行）。 我们还需要支持“假设”场景（并行模型）。 我相信模型驱动的方法将帮助我们管理复杂性，因此我希望尽可能地将逻辑保留在数据库之外。
我的问题是针对尝试过 EagerReadDerivation 模式的开发人员：它是否为您带来回报，是否值得在应用程序中增加额外的复杂性？
I'm studying Domain-Driven Design and Distributed DDD for an upcoming Silverlight application I'm going to be working on. The EagerReadDerivation pattern seems like it would improve the scalability of the application, but at the cost of increased complexity.
The application will have potentially have thousands of users uploading large text files (100,000+ lines) that will need to be processed by multiple services. We'll also need to support "what-if" scenarios (a la ParallelModel). I believe a model-driven approach will help us manage complexity so I'd like to keep logic out of the database as much as possible.
My question is for developers that have attempted the EagerReadDerivation pattern: did it pay off for you, and was it worth the additional complexity in your application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要估计好处，您应该考虑上传/查询比率。
如果您的查询数量多于上传数量，那么您一定应该对上传进行处理。
它还导致更可重复的模式，数据在完全处理之前无法查询。 如果在读取时应用逻辑，则在应用读取逻辑时更改数据时会出现问题。
无论如何，按照您的计划将逻辑保留在数据库之外。
To estimate the benefits, you should consider the upload/query ratio.
If you have fare more queries than uploads, you should definitly apply processing on upload.
It also lead to a more repeatable pattern, the data cannot be queried before it has been fully processed. If apply logic on read, a problem arise when changing the data while applying logic for read.
By all mean, leave logic out of the database as you planed.