locked
DomainService Lifespan question RRS feed

  • Question

  • I've found some great posts on DomainService internal Lifecycle, like this one: http://weblogs.asp.net/fredriknormen/archive/2009/12/29/wcf-ria-services-domainservice-life-cycle-and-adding-transactions.aspx 

    But I've been unable to find anything in regards to the lifespan of the DomainService. If anyone knows of an over all resource on this, I'd love to see it.

    My current questions in regards to Lifespan:

    Is an instance of a DomainService created to only handle one operation from the client side DomainContext?

    Is there any possibility of a DomainService being reused for multiple operations from a single client?

    Is there any possibility of a DomainService being reused between multiple clients?

    I'm looking at implementing PersistChangeSet on a DomainService to roll up multiple changes into a Transaction, and I want to make sure multiple users don't step on each other :)

    Monday, November 21, 2011 6:57 PM

Answers

  • The answer depends on your defintion of an "operation". Do you define an operation as a single entity change, or an entire changeset submit operation, as one operation. (e.g. insert 3 entities at once, 1 operation, or 3?). In either case:

    Is an instance of a DomainService created to only handle one operation from the client side DomainContext?

    A new instance is created for each changeset, and for each query. i.e. So a changeset with multiple entities in it, occurs in a new single instance of your domain service; each changeset occurs within it's own seperate instance.

    Is there any possibility of a DomainService being reused for multiple operations from a single client?

    If you define an operation as an entire change set, by default no. I'm not an expert on this but you "may" be able to use a domain service factory to return a single instance, although this is not standard practice so I would assume that it is not recommended.

    Is there any possibility of a DomainService being reused between multiple clients?

    By default no. Each changeset has it's own instance. As mentioned above, you may be able to do some trickery with a domain service factory.

    I'm looking at implementing PersistChangeSet on a DomainService to roll up multiple changes into a Transaction..

    Ria was created specifically to provide this sort of end point by default. RIA + EF by default is already transactional, it will either persist the entire transaction, or none of it (and return the exception)

    Monday, November 21, 2011 8:28 PM

All replies

  • The answer depends on your defintion of an "operation". Do you define an operation as a single entity change, or an entire changeset submit operation, as one operation. (e.g. insert 3 entities at once, 1 operation, or 3?). In either case:

    Is an instance of a DomainService created to only handle one operation from the client side DomainContext?

    A new instance is created for each changeset, and for each query. i.e. So a changeset with multiple entities in it, occurs in a new single instance of your domain service; each changeset occurs within it's own seperate instance.

    Is there any possibility of a DomainService being reused for multiple operations from a single client?

    If you define an operation as an entire change set, by default no. I'm not an expert on this but you "may" be able to use a domain service factory to return a single instance, although this is not standard practice so I would assume that it is not recommended.

    Is there any possibility of a DomainService being reused between multiple clients?

    By default no. Each changeset has it's own instance. As mentioned above, you may be able to do some trickery with a domain service factory.

    I'm looking at implementing PersistChangeSet on a DomainService to roll up multiple changes into a Transaction..

    Ria was created specifically to provide this sort of end point by default. RIA + EF by default is already transactional, it will either persist the entire transaction, or none of it (and return the exception)

    Monday, November 21, 2011 8:28 PM
  • The answer depends on your defintion of an "operation". Do you define an operation as a single entity change, or an entire changeset submit operation, as one operation. (e.g. insert 3 entities at once, 1 operation, or 3?). In either case:

    Yes, I'm defining a single operation as a ChangeSet, i.e. DataContext.SubmitChanges() or calling an [Invoke] function.

    Is an instance of a DomainService created to only handle one operation from the client side DomainContext?

    A new instance is created for each changeset, and for each query. i.e. So a changeset with multiple entities in it, occurs in a new single instance of your domain service; each changeset occurs within it's own seperate instance.

    That's what I was hoping for, it seems to be difficult to run down documentation on that.

    Is there any possibility of a DomainService being reused for multiple operations from a single client?

    If you define an operation as an entire change set, by default no. I'm not an expert on this but you "may" be able to use a domain service factory to return a single instance, although this is not standard practice so I would assume that it is not recommended.

    So outside of doing something like a custom DomainServiceFactory using singletons, I don't have to worry about CUD operations from different changeset operations getting crossed.

    Is there any possibility of a DomainService being reused between multiple clients?

    By default no. Each changeset has it's own instance. As mentioned above, you may be able to do some trickery with a domain service factory.

    I'm starting to sound paranoid :)

    I'm looking at implementing PersistChangeSet on a DomainService to roll up multiple changes into a Transaction..

    Ria was created specifically to provide this sort of end point by default. RIA + EF by default is already transactional, it will either persist the entire transaction, or none of it (and return the exception)

    I'm used to the really cool features like this to have nasty gotchas :)

    Monday, November 21, 2011 8:55 PM