2

I'm currently building an ASP.Net MVC 4 SAAS application (C#) and am stuck on designing the plans. I mean if a customer picks Plan A they should have access to some things and if they pick Plan B they get access to others and so on.

The Part that I'm stuck on is be best practice of sharing the account's plan with all of the actions. I realize having global variables are bad practice and all but I really don't want to take round trips to the DB to get the plan on every action.

What I'm thinking of doing is something like This SO answer where they just declare a static model and set it at some point and access it later on. In your opinion, is this the best way of doing this? is there a better way?

Improve this question
4
  • but I really don't want to take round trips to the DB to get the plan on every action Below approach is going to make db call on each action. Correct ? Commented Jul 27, 2013 at 13:52
  • @PKKG: there is a check to ensure that we load only once. Commented Jul 27, 2013 at 14:13
  • @Khanh : That is the memory of Interface not the memory of data. right ? So, each request for action will go to db Commented Jul 27, 2013 at 14:17
  • @PKKG: there is only 1 instance of IConfigService interface if we configure this instance as singleton in our IoC (our IoC holds a reference to it) and reuse it throughout the app. Commented Jul 27, 2013 at 14:21

1 Answer 1

Reset to default
5

I think best practice is you should include an IoC in your project and inject a configuration object to your controller.

Example code of a controller:

public class YourController : Controller { private IConfigService _configService; //inject your configuration object here. public YourController(IConfigService configService){ // A guard clause to ensure we have a config object or there is something wrong if (configService == null){ throw new ArgumentNullException("configService"); } _configService = configService; } }

You could configure your IoC to specify singleton scope for this configuration object. In case you need to apply this pattern to all your controllers, you could create a base controller class to reuse code.

Your IConfigService 

public interface IConfigService { string ConfiguredPlan{ get; } }

Your ConfigService:

public class ConfigService : IConfigService { private string _ConfiguredPlan = null; public string ConfiguredPlan { get { if (_ConfiguredPlan == null){ //load configured plan from DB } return _ConfiguredPlan; } } }
  • This class is easily extended to include more configurations like connection String, Default timeout,...
  • We're passing in an interface to our controller class, it's easy for us to mock this object during unit testing.
Improve this answer
Sign up to request clarification or add additional context in comments.

11 Comments

Wow, I really like this solution. I will try to implement it tomorrow. Thanks!
me too :) I'm really a newbee when it comes to DI. I really have to start thinking that way
You are saying IOC, but this is Dependency Injections? You are injecting the Interface(dependency) in Constructor.
@PKKG: you should know the differences between these terms. Dependency Injection is a set of software design principles and patterns that enable us to develop loosely coupled code. IoC or DI container is a software library that provides DI functionality. Hope it's clear. Have a nice day.
So internally, Inversion of Control does Singleton Pattern Class Implementation ?
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.