At my company, we have a solution composed of a WinForm (multiple per client) and an API (one per client). This solution is deployed on different clients that require the solution to behave differently according to their desires. The same code base must support UI customizations (client logo, buttons visibility) and functionality customizations (calling the same WebMethod with different flags).
Currently we manage this flexibility on the WinForm side by having an
Organization class that contains all these customizations (flags). The API is totally client-agnostic. Thus, the WinForm's methods look like this:
this.Logo = CurrentOrganization.LogoImage; API.GetProducts(Organization.UsesPagination);
In the past, we had conditional build directives scattered among the code:
#IF CLIENT_A API.GetProductsWithPagination(); #ELSE API.GetProducts(); #ENDIF
Today, we have a single zone with those conditional build directives that, according to the build configuration, instantiates the required
Organization class. Afterwards, there are no more IFs, parameter passing.
I'm a bit worried this is not the best design or the most maintainable solution. I studied the State pattern... I guess the
Organization is my strategy object, since it tells other methods how they should behave through flags.
Is there a better way?
- Storing configurations on a DB table? (requires more requests to the API, which costs time)
- Storing configurations on a *.config files? (someone can easily change the app behavior by editing the file)