RIA 域服务应包含多少个实体？
我想知道如何在 RIA 中准确实现域服务。将整个域模型中的所有实体包含在单个域服务中，从而使该服务负责整个数据库，是否很常见？这是通常的做法吗？我确实没有理由将数据访问分离到不同的服务中，但我想知道这是否被认为是一个好的做法，以及这种方法的优点和缺点是什么。
另外，将域上下文注册为 IOC 单例，以便整个应用程序使用同一组数据，从而避免并发问题和类似问题，这被认为是好还是坏做法？
想法？
谢谢
I was wondering about how to exactly implement domain service in RIA. Is it common to include all entities in the entire domain model in a single domain service, thus making the service responsible for the entire database? Is this the way it's normally done? I really have no reason to separate data access into different services, but I was wondering if this is considered a good practice, and what the pros and cons of such an approach would be.
Also, is it considered a good or bad practice to register domain context as a singleton with IOC, so that the entire application works with the same set of data, thus avoiding concurrency issues and similar problems?
Thoughts?
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们的应用程序中有两项独立的服务：一项用于数据模型，一项严格用于身份验证。我们从 MS 的业务示例应用程序结构中采用了此设计。
我们考虑过将数据域服务分解为更小的组件，但决定不这样做，因为它似乎没有增加任何优势（除了减少服务类大小之外）。如果您有彼此完全独立的不同数据模型，那么就这样做路线可能有意义。直观上，领域服务应该代表整个领域。如果您的域是独立的（偶尔需要交叉< /a>) 那么以这种方式隔离它们就具有逻辑意义。
关于使用上下文作为单例：我尝试过，最终创建了类范围实例。我们这样做没有遇到任何问题，因为它们都使用相同的底层数据连接。我不知道“官方”最佳实践是什么，但这是我在众多 RIA 应用程序中看到的做法。
We have two separate services in our app: one for the data model and one strictly used for authentication. We took this design from MS's business sample app structure.
We considered breaking up our data domain service into smaller components but decided against it because it didn't seem to add any advantage (other than reducing service class size.) If you have distinct data models that are completely independent from each other then going that route might make sense. Intuitively the domain service should represent the entire domain. If your domains are independent (with the occasional need for crossover) then it makes logical sense to segregate them in that way.
Regarding using the context as a Singleton: I tried that and ended up creating class-scope instances instead. We haven't experienced any issues doing it this way as they all use the same underlying data connection. I don't know what the "official" best practice is, but this is the way I've seen it done in numerous RIA apps.
谢谢尼克。我实际上做了和你一样的事情，我构建了两个服务，一个用于身份验证，一个用于数据访问。这对我来说似乎最合乎逻辑。
至于使 datacontext 成为单例，我也尝试过并且效果很好。无需不断地重新加载和刷新数据并担心其他类的并发问题:)
Thanks Nick. I actually did the same thing as you, I built two services, one for authentication and one for data access. That seems most logical to me.
As for making datacontext a singleton, I've tried that as well and it works nicely. No need to constantly reload and refresh data and worry about concurrency issues in other classes :)