I am using StructureMap on an ASP.NET MVC project. I have an object that I want to use throughout the session. Should I use StructureMap or Session:["MyObject"] to manage the concrete instance? Thanks in advance.
This will depend on your scenario. If this instance is tied to a particular user and should not be shared between other users you should use Session. For example use Session to store products that the user added to his cart in an e-commerce application.
If it is for injecting dependencies such as repositories into your controllers and managing controllers StructureMap is fine.
Related
I am implementing a custom ASP.NET membership provider that operates based on the custom repository class that in turn uses an Entity Framework DbContext as a mean of accessing a data.
Since this is an ASP.NET MVC application, IoC container (Ninject) is set to resolve instances of my DbContext InRequestScope.
My user data tables are a part of the single main DbContext.
Repository class is also bound to instantiate in InRequestScope. But the repository class is created by to satisfy the need of the custom MembershipProvider, which can't be set to instantiate InRequestScope. As a result, whenever I am trying to access Role data via repository, I get DbContext is already disposed exception.
Has anyone set up a similar configuration and if so, what was implemented differently to overcome the problem I am having. Thanks.
A workaround that has allowed me to continue with the project development was to manually create an instance of DbContext in Membership Provider constructor, in contrast to have Ninject inject it.
Maybe someone eventually will come up with a better approach to this particular problem, please post it here and I will remark it as an answer instead of this workaround.
I have a MVC app that uses ninject to inject service dependencies into controllers and it works well. However I also have some domain objects that require these services in their constructors and I want to resolve these dependencies using ninject, but don't want to reference ninject directly in my domain objects assembly. I have read lots of questions and answers here but its still not clear to me the best way to go about this. For example I have a ShoppingCart domain object that needs an instance of a IProductCatalogService passed to its constructor. What is the best pattern to create an instance of a shopping cart? I could have a reference to the root kernel and call out to that, but that would mean having references to ninject throughout my domain assembly. Should I wrap access to the kernel in a factory class?
Any thoughts or suggestions welcome!
It is usually considered bad practice to have services in domain objects. I think you need to rethink exactly what you are attempting to achieve. Why does a ShoppingCart need to consume Product Catalog Services?
From a Domain perspective I would assume that a ShoppingCart would consist of many 'items', have properties like total etc and potentially would be passed to an ordering service. Your controller actions would update the Shopping Cart domain by adding items, removing items, etc, etc.
If you really need to consider this option, is to use commonservicelocator. This will separate out your (direct) dependency on ninject.
Hi we have a third party application that exposes a web service for use in building websites. It handles createing sessions , getting product data, shopping cart, and check out calls to the database. I am new to MVC and my question is how do I work this webservice into my mvc site i am building, I want to take advantage of testing as well. I can not change the access to the database, I have to use the web service.
Thanks!
Jon
I usually deal with the data access using a services pattern. In your case I'd have an interface like IProductsService with the usual methods GetProducts(), GetProduct(id) ... and so on. By coding against that interface your controller will not care about where the data is coming from, so you would declare and use your dependency as
private IProductsService _productsService
...
IEnumerable<Products> products = _productService.GetProducts();
This comes quite handy for testing purposes too, as with IoC you can inject a different service (one that returns a hardcoded list for example) depending on your test cases. Eventually if you guys switch to a different strategy and access the data store directly you only need to create a new service, implement the interface and inject that one instead.
I'm trying to be a Good Developer and separate my concerns out. I've got an ASP.NET MVC project with all my web code, and a DAL project with all the model code.
Sometimes code in the DAL needs to check if the current user is authorized to perform some actions, by checking something like CurrentUser.IsAdmin.
For the web site, the current is derived from the Windows username (from HttpContext.Current.User.Identity), but this is clearly a web concern and shouldn't be coupled to the DAL.
What's the best pattern to loosely couple the authentication? Should the DAL be asking the MVC code for a username, or the MVC be telling the DAL? Are there advantages or disadvantages to one or the other?
Thank you!
Typically I handle the security at the controller level, not at the data level. If you want to handle it at the data level, then I'd use injection to give your DAL either the current user or the means to access who the current user is. In this case it would mean injecting the User object from the Controller when you create the DAL instance. I sometimes do this for auditing, i.e., the current user may be a member of a role that allows access to a modify a user's data. In that case I want to insert the actual user making the change into the audit table. I would avoid using HttpContext.Current -- you should use the properties on the controller instead and inject them rather than having the DAL obtain them from a static object. That will make your DAL much easier to test.
When handling security in the controller you can use the AuthorizeAttribute or custom attributes derived from it to implement your cross-cutting security concerns.
I have a a model class that needs access to my repository class (used for DB access).
I have created an interface for my repository and have successfully configured Castle Windsor to inject my the appropriate IRepository-based class into my controllers via a custom ControllerFactory.
I'm having a little more trouble figuring out how to do the same thing with my model.
Does anyone know of a way to use Windsor to inject a dependency into an MVC model?
As an aside, the reason I need Windsor to handle this is because MVC automatically instantiates an instance of my model when data is posted to my controller, and this automatic instantiation doesn't allow for me to pass any constructor parameters.
You may want to take a look at MVC Contrib's Castle Binder.
However, personally, I think that Models should be simple POCO's, or dumb containers of data, free of any DI. In this approach, it is the Controller's responsibility to read, manipulate and persist data.