Is one available?

Updated at 02.02.2010 2:00:38

Good approach. I imagine many of your customers (including us) develop enterprise software. In enterprise software, we have many clients, and each client wants their own customizations of processes and workflows.

So supporting IoC is a very good idea, as I can have several implementations of IMyService (e.g. one for each client), but only register a particular one for a particular client's implementation.

Which begs the question... is there a mechanism for registering services? I want to be able to register a particular IMyService implementation to be returned, even if there are multiple IMyService implementations in the assembly.

Updated at 31.03.2010 0:03:31


So, just as in your example ;)

[Service(typeof(ICustomerService))] public class CustomerService : SessionBound, ISessionService { public IQueryable<customer> GetCustomersWithBalances() { return Query.All<customer>().Where(c => c.Balance > 0); } }

.... in client code var service = Session.Services.Get<icustomerservice>().GetCustomersWithBalances()

Is there anything I'm missing? Any best practice considerations?

This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Jan 31 '10 at 17:11

ara's gravatar image


One Answer:

Yes - it's SessionBound. They're available via Session.Services property.

Btw, I'm significantly changing this part right now (this is tightly related to common IoC pattern we use, and that's what I'm working on), so after this refactoring you'll be able to use nearly the following code:

public class MyService: SessionBound, ISessionService


var myService = mySession.Services.Get<IMyService>()

Nearly the same approach will work for Domain.Services. Moreover, we're going to open access to various internal stuff using this approach, e.g.

var sqlHelper = session.Services.Get<SqlHelper>();
var dbCommand = sqlHelper.CreateCommand();

Yes, it will be possible. Currently you should set Domain.Services.SetServiceLocator, which (as I consider) is wrong approach (it was actually one of quick temporary solutions). It's wrong, because it allows to modify the setting after the configuration. So shortly it will work as follows:

1) If nothing special is done, we'll use our own IServiceContainer implementation. It will allow to access the services available in DomainConfiguration.Types, mapping here is done via [Service] attribute and/or configuration section.

2) If DomainConfiguration.ServiceContainterType is specified, we'll use its instance instead of our own; our own container will be chained after it (now we have ChainingServiceContainer). So basically, your own container can override anything.

IServiceContainer is identical to IServiceLocator from CommonServiceLocator project (I re-declared it in Core.IoC just to get rid of CommonServiceLocator assembly reference - we always get complains too many assemblies must be referenced to use DO4, so we slowly reduce this number). So generally any IoC container type can be used with DO4.


No, this won't work on the client, if any remote interaction is implied, because all these objects aren't MBR objects now.

Preliminary version of pattern for remote services is shown in Xtensive.Storage.Samples.Wcf.*. Soon it will be polished, but for now this demonstrates the whole idea.

The latest version in repository (already in stable branch) uses typed results:

  public interface IOrderingService
    // Customer operations

    CustomerResult GetCustomerById(int id);

    CustomerResult GetCustomerByName(string firstName, string lastName);

    CustomerListResult GetAllCustomers();

    // Product operations

    ProductResult GetProductByName(string name);

    ProductResult GetProductById(int id);

    ProductListResult GetAllProducts();

    // Order operations

    OrderResult GetOrderById(int orderId);

    OrderListResult GetCustomerOrders(int customerId);

    void SaveOrders(ModificationSet modifications);

TODOs for us:

  • Improve SaveOrders - currently it returns nothing, but ideally it must return either a set of remapped keys & new versions, or an explicit "refresh the UI by re-query" flag (this is the only supported "result" now - i.e. it is void ;) ).

  • Convert this console sample to WPF sample (in progress).

  • Improve DisconnectedResult<t> & ModificationSet and move them to Storage - in particular, we must support compression there.

answered Feb 01 '10 at 20:54

Alex%20Yakunin's gravatar image

Alex Yakunin

Alex, could you please update the manual for this? I really need it.

Or at least a quick example please.

(Feb 01 '10 at 20:54) ara ara's gravatar image

So I just closed this issue (+ a set of another, related ones). The description will follow up in Manual & my blog shortly.

(Feb 01 '10 at 20:54) Alex Yakunin Alex%20Yakunin's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview


Once you sign in you will be able to subscribe for any updates here



Asked: Jan 31 '10 at 17:11

Seen: 4,020 times

Last updated: Jan 31 '10 at 17:11

powered by OSQA