Wirebox and Multi-Tenant app best practice

Hi,

I have a multi-tenant app where each client has their own database with its own CF datasource. The database schema for each client is the same. The user logs in and we session their datasource. Let’s say I have a service called Company that has a bunch of methods like ‘GetEmployees(dsn,firstNameStartsWith)’ and ‘GetAddresses(dsn)’ that I want to use as a singleton.Is there some way in wirebox to automatically wire in the dsn argument? Or will i need to manually pass it in?

Thanks.
Brett

WireBox can certainly wire in the DSN, but assuming that you have a bunch it would need to wire them all in and then you’d need logic inside the component that decided which DSN to use at run time. I’d recommend creating some sort of service that had all the logic to decide what DSN in to use. Wire THAT service everywhere and just ask it for the DSN you need at run time.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Brett,

I’d be interested in hearing if you’d had any problems with Multi-domain stuff.

But, back to the problem in hand, I solved this by setting the application name & ORM datasource after doing some checks to confirm their target DB. This way, each client has their own separate instance of the application too. I also set the DSN into the server scope, which i can reference by a Client UUID set into the users session/cookie.

So, server[cookie.clientUUID].datasourcename or equiv.

Many Thanks,

Alex

Though probably only in part, I have a similar situation where I have an application level data source and a client level data source but use the same model for both. When the application launches (prior to determining the client) I have one wirebox implemented to handle the application. Then, when the client is “detected”, I create another wirebox for the client needs. However, when creating the client wirebox, I use properties to harvest and pass on the target data source I need. It works wonderfully.

Mike

…keeping in mind I had legacy code with which to contend…given the opportunity to start from the ground up, I guess I would not have taken this path.

Mike

Thanks everyone for responding.

@Brad: That seems like a very simple and effective way to handle it and I like it a lot. I also was looking at the ‘Scope Widening Injection’ section of the wirebox docs where it talks about using a ‘provider’ to inject in a user. Is this perhaps another way this problem could tackled?

@Alex: We don’t do multi-domains. Everyone goes to the same URL and logs in and assuming validation passes we session the datasource name along with other user data points. We have 100s of clients using this application, and hopefully 100s more using it by the end of 2014. I would be concerned from a memory perspective having each client load up their own instance of the application, but that might just be ignorance masquerading as paranoia.

@Mike: This application would be a port of another coldbox application we have. The previous application only had a single datasource, so that datasource was just wired in as a property to all my singletons. Now that my singletons can have that datasource change I was looking for a way to refactor the services without having to specify the datasource I’m using every time I call one of its methods.

You wouldn’t be using a provider to avoid scope-widening injection, but you can certainly use a provider to do the work of the service I talked about. A provider is simple a CFC that is injected in place of “the real thing” and tasked with creating and optionally scoping that thing when called upon. There is a default provider, but you can create your own provider CFC that extends our provider interface and then inject that provider CFC instead and ask it to give you the dependency.

Honestly, if i were you I’d just stick with the service concept. It’s essentially the same thing in practice, but a bit more familiar to other devs.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Brad,

I’m pretty sure I will be following your initial recommendation and just injecting some type of DSN Service into my singletons.

Thanks.
Brett