Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The web application I work on has been live for a year now, but it's time for it to evolve and one of the ways in which it is evolving is into a multi-brand application - in this case several different companies using the application, different templates/content and some slight business logic changes between them.

The problem I'm facing is implementing a best practice across the site where there are differences in business logic for each brand. These will mostly be very superficial, using a an alternative mailing list provider or capturing some extra data in a form.

I don't want to have if(brand === x) { ... } else { ... } all over the site especially as most of what needs to be changed can be handled with extending the existing class.

I've thought of several methods that could be used to instantiate the correct class, but I'm just not sure which is going to be best especially as some seem to lead to duplication of more code than should be necessary.

Here's what I've considered:

1) Use a Static Loader similar to Zend_Loader which can take the class being requested, and has knowledge of the Brand and can then return the correct object.

$class = App_Loader::getObject('User', $brand);

2) Factory classes. We use these in the application already for Products but we could utilise them here also to provide a transparent interface to the class.

3) Routing the page request to a specific brand controller. This however seems like it would duplicate a lot of code/logic.

Is there a pattern or something else I should be considering to solve this problem?

4) How to manage a growing project that has multiple custom instances in production?

Update This is a PHP application so the decisions on which class to load are made per request. There could be upwards of 100+ different 'brands' running.

share|improve this question
1  
What's a multi brand application? –  Yannis Rizos Jun 26 '12 at 9:36
1  
@PhilCarter, what do you mean by "brand"? each brand = separate client? Is your application is slightly modified and used by different clients? –  Yusubov Jun 26 '12 at 10:07
2  
Is you question - "How to manage a growing project that has multiple instances customized ans sold to clients?" –  Yusubov Jun 26 '12 at 10:12
1  
@ElYusubov - yes each brand is a separate client with slight modifications to the app. –  Phil Carter Jun 26 '12 at 10:33
1  
@PhilCarter - the buzzword for this is "multitenancy". separate everything that a company/brand might want to customize (be it content or business logic) and create a templating system for it. –  devnull Jun 26 '12 at 12:56
show 2 more comments

4 Answers

Question is - How to manage a growing project that has multiple instances customized and in production with some customization in core project? Answer is - through custom configuration process build into your core project.

Here you are some configuration suggestions from MSDN - Managing Configuration Options. This can be used as an idea how to configure your so called "multi-brand" project.

You may also need to plan a strategy for deployment of custom projects that have sharing core functionality: Here is an example for .NET platform which might be used as an idea. MSDN - Project Configuration for Managing Deployment

share|improve this answer
add comment

I think either of your first two suggestions should do the trick. The third option will result in too much duplication which increases your risk for code defects to slip into the production stream.

At a broader level, the first two options are essentially the same logical path and the difference is where they execute. You and your peers are in the best position to determine the least disruptive means for inserting the change.

If you haven't done so already, having a common config module will streamline some of the changes you're suggesting. Apologies in advance for suggesting the obvious but I wanted to make sure it was brought up.

If you haven't already, map out the various use cases that you're likely to see. It will give you a framework to refer back to when thinking through the design and test cases to generate. As others have pointed out - more common code means an increased risk of disabling many client sites from one bug. Automated regression / stability testing are going to help with mitigating that risk. Ditto with dev / test / prod environments, but I'm assuming you already have that in place.

share|improve this answer
add comment

I would be storing different configuration options in a database and writing a configuration application.

This way you can load the configuration by "brand". Any new functionality which is brand sepcific can be configured on future brand sites, without modifying code.

if (brand=="x") is essentially hard coding, avoid it, you would be better to code something like if (configObject.IsFeatureSwitchedOn)

EDIT: You are thinking of having one deployed instance running multiple brands? Don't do it, it will be a maintenance and scalability nightmare.

share|improve this answer
    
All the configuration is split out into a config file. This could work, but in some cases there might still be several if/else if/else so it would be best to get the specific child class i.e. X_User or Y_User etc. –  Phil Carter Jun 26 '12 at 9:54
1  
I suppose it depends how big you intend go. In enterprise software such are Microsoft Dynamics AX, everything is parameterised. The "brands" are called "companies" and adding new functionality to one makes it available to the others by setting up parameters. –  AnthonyBlake Jun 26 '12 at 9:58
    
+1 This is the same approach I have used successfully in the past. You choose what to load (BL, UI and etc) to load and how to connect them according to the config. If you can load derived classes based on their names or a similar technique you will not need if (project == "X") anywhere in your code. –  Danny Varod Jun 26 '12 at 11:10
add comment

First my experience with what another company has done before: They had exactly the same live code used by several of their clients, with just skin changes, and lots of conditional logic behind. It meant that if one of their clients went down because there was a bug in the code that was just promoted, every single of their clients went down. So have that in mind. You want to have separate deployments (one would think that is the common sense thing to do)

I'm wondering if the easiest thing to do is to implement Strategy patterns whenever you have to do something different. Then, as the number of strategies grow, you can consolidate them together in a class, with subclasses for each different brand, that are initialize by a factory.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.