http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Manuel, I use several techniques, based on how this is supposed to work from the client perspective. a) host name b) common login and than by the login data c) geo location d) telepathy http://ayende.com/3446/the-importance-of-context#comment7http://ayende.com/3446/the-importance-of-context#comment7Tue, 29 Jul 2008 13:29:23 GMTHi, I agree with your design, some years ago I made some .net 1.1 projects with the same design approach, my simple and little question is what kind of "object discriminator" you use to create uniquely per-user object? I'll explain better, I think there's a place where you decide to create "contextual" objects, this deciding is made by what? maybe can you post an example? just to make what's the difference between mine and yours implementation Ciao http://ayende.com/3446/the-importance-of-context#comment6http://ayende.com/3446/the-importance-of-context#comment6Mon, 28 Jul 2008 23:52:42 GMTJoao, Yes, that works, but... a) It requires special attention to ensure that you always qualify by the client id. b) sharding is hard or impossible c) you can't let the client have a backup of the client's data http://ayende.com/3446/the-importance-of-context#comment5http://ayende.com/3446/the-importance-of-context#comment5Sat, 26 Jul 2008 16:27:09 GMTI've solved this problem in a different way: one database, and most tables have an extra uniqueidentifier column that identifies the client. Then I map each client to their own virtual directory in IIS. A binsor config extends the embedded config, injecting some credentials into the ServiceModel (referencing that uid). The client must supply these same credentials when connecting. http://ayende.com/3446/the-importance-of-context#comment4http://ayende.com/3446/the-importance-of-context#comment4Sat, 26 Jul 2008 16:24:08 GMTI don't have a context object, in most cases. The context is implicit, as I said. You get the IAuthService in the ctor. Agreed about the configuration, btw http://ayende.com/3446/the-importance-of-context#comment3http://ayende.com/3446/the-importance-of-context#comment3Sat, 26 Jul 2008 08:30:16 GMTI didn't quite understand something, do you still have a Context object? Or do you use IoC.Resove<IAuthenticationService> and let the container take care of it? I see a similar problem with configuration (app.config etc). We're having a debate on my current project. One opinion is that the config is a service that should be relied upon and used by the entire application, at any level. I don't like this, I'd rather that classes were configured during instantiation using the constructor, or by the IoC container, or by a factory (that might decide to use the app.config). That makes it more testable, more explicit, and flexible. How do you deal with this? http://ayende.com/3446/the-importance-of-context#comment2http://ayende.com/3446/the-importance-of-context#comment2Sat, 26 Jul 2008 08:24:46 GMTI definitely agree that seperate database per client is best if you can deal with the management issues. Much easier to do that with a handful of clients than hundres, but it takes so much extra work out of the equation when the clients are really supposed to be isolated. http://ayende.com/3446/the-importance-of-context#comment1http://ayende.com/3446/the-importance-of-context#comment1Sat, 26 Jul 2008 00:03:48 GMT