I would like to know your opinion on using MVCExtensions with Autofac..
I am using MVC Extensions with Autofac in my MVC 3 web app. I'm just not getting it why these extensions were created? I can't really say that it is makng my life easier. Everything that I did with Autofac in my global.asax.cs file I can do with the MVC extensions. I can register routes, controllers, my services and repositories, etc with just Autofac.
Any opinions why using these MVC extensions is maybe a better way to go?
I need to capture my errors in Application_Error. How do I get an instance of my registered logger? If I need to resolve dependencies some where else in my app how would I do this? This is how I register my logger:
builder.RegisterType<Logger>().As<ILogger>();
I can instantiate my logger but would rather like to use the registered logger.
Is there a tag for these extensions?
You should be able to access your logger through the DependencyResolver:
var logger = DependencyResolver.Current.GetService<ILogger>();
Related
I'm working in a MVC project, which has several controllers. Each has in the beginning
private static readonly ILog Logger = LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
In c#, I was using loggers in exception. I can't understand why each controller has its own logger.
hi it looks like log4net declaration. its a tool to log your error in all kind of .net program like web app ,console, windows etc. so that exceptions are logged and developers know what exactly gone wrong am mentioning link for a tutorial if you want additional information on matter.
https://www.codeproject.com/Articles/140911/log-net-Tutorial
I just installed MVC5 and ServiceStack.Host.Mvc into a empty ASP.NET project. MVC for the Routing, Bundling/Minification and ServiceStack for everything else (IoC, Cache, ect.). This site will only be used to deliver views (SPA Islands I call them) and these rendered views will in turn call another ServiceStack RESTful API site.
So my questions is this "Since I have to bootstrap ServiceStack with the AppHostBase which wants an assembly with a Service in it, is there any harm if I just use the current assembly with-out any services as the snippet below illustrates?"
public AppHost()
: base("Website UI", typeof(MyRootNamespace.Global).Assembly) { }
Everything still seems to work in controllers that inherit from ServiceStackController, at least the IoC.
Thank you,
Stephen
Nope, ServiceStack just uses the list of assemblies specified in the AppHost constructor to scan and autowire any IService's it can find in those assemblies, which in this case there just wont be any.
I am trying to properly use Ninject to inject log4net logging into my MVC3 application. I am using the Ninject.MVC3 package, so I have the NinjectMVC3 class that automatically extends the App_Start method and contains the RegisterServices method that binds all dependencies. I also have the Ninject.Extensions.Logging.Log4Net package, but I don't know how to use it. I already know how to configure log4net in my web.config, but don't know how to use this extension for DI.
I have read all the following articles/posts, but none of them seem to define how to properly setup a project for DI logging.
At http://dotnetdarren.wordpress.com/2010/07/29/logging-in-mvc-part-4-log4net/, Darren
provides a great article, but doesn't seem to deal with DI (at least I don't see it).
At Using Ninject to fill Log4Net Dependency,
Remo Gloor states here that the extensions should provide all that's needed for implementation, but it doesn't show the code of how to instantiate it.
The documentation for ninject.extensions.logging at https://github.com/ninject/ninject.extensions.logging/wiki/Using is very limited at best. I have re-read it many times, and still don't see how to use bind the injection in the NinjectMVC3 class, or concrete examples of how to call the logger from my controller class for example.
At the most promising article, Moosaka provides some great code at Ninject.Extensions.Logging.Log4net unexpected behavior, but when I try it, I get a compile error in the LoggerFactory at ILogger logger = new Logger(type); stating "Cannot access protected constructor 'Logger' here". Also, he states to "Tuck this whole mess away into a separate class library". Does that mean as a whole separate project?
I'm just getting lost in all the differing options and dated posts and would like any input on how to use Dependancy Injection with Ninject and Log4Net in my MVC3 project. Also, if it matters, all of my Ninject code is in my domain project, but the logging needs done from both the domain and web project (and mocked in my unit tests). Any help is appreciated.
You shouldn't have to configure anything except the normal log4net config.
All you have to do is to inject a ILogger wherever you want to log.
https://github.com/ninject/ninject.extensions.logging/wiki/Using
I am working on an ASP .NET Mvc 3 App and have installed Ninject.Mvc3 using Nuget. I now have the App_Start folder and then ninject class. I have seen plenty of examples on how to configure NHibernate in the Global.asax file. So how do I configure the session before handing it Ninject if I am using the Web Activator class? Do I just do it like normal in the global.asax?,
Bob Cravens has a nice series of posts on how to do this:
Using the Repository Pattern with MVC and NHibernate
http://blog.bobcravens.com/2010/06/the-repository-pattern-with-linq-to-fluent-nhibernate-and-mysql/
Using an IoC container (like Ninject) with a NHibernate inside ASP.NET MVC
http://blog.bobcravens.com/2010/07/using-nhibernate-in-asp-net-mvc/
Any responsible web developer knows that managing / disposing of objects and resources is critical to good web application development. Please make sure and read this bit too :-)
http://blog.bobcravens.com/2010/11/using-ninject-to-manage-critical-resources/
I don't know which example you are refering to. But for most of them you can do it the same way.
Now, in App_Start folder you have a file called NinjectMVC.cs, there is a method:
private static void RegisterServices(IKernel kernel)
{
}
You have to register all your services there, just the same way you did in global.ascx before.
While developing web project using ASP.NET MVC, I came up against a coupling problem.
When I build custom controller factory (or dependency resolver if using MVC 3), I need this factory to know somehow where to get dependencies from. Here's my code:
//from Global.asax.cs
DependencyResolver.SetResolver(new StructureMapControllerFactory());
class StructureMapControllerFactory: IDependencyResolver {
Container repositories;
public StructureMapControllerFactory()
{
repositories = new RepositoriesContainer();
}
//... rest of the implementation
}
class RepositoriesContainer: Container
{
public RepositoriesContainer()
{
For<IAccountRepository>().Use<SqlAccountRepository>();
//...
}
}
StructureMapControllerFactory class is responsible for injecting dependencies into a controller. As I said, it needs to know where to find these dependencies (I mean concrete classes, like services and repositories implementations).
I have a separate class library called MySite.Data, where all the implementation details live. Contracts, like IAccountRepository, live in library MySite.Contracts. Now, if I reference this MySite.Data library directly from MVC project, there will be a dependency between my site and implementation of its data retrieval. The question is how can I remove it? What are best practices in this situation?
I'm sure it does have a bunch of workarounds, just I haven't found any yet.
Well, as I see it, you can't do exactly that. Your MVC project really really needs to know about concrete classes it is going to use.
You will anyway have to provide those container registrations somewhere and you'll get the dependency on the project/assembly where that type is defined. Shortly, you have to reference MySite.Data from MVC project. Like that:
MySite.Data knows nothing about MVC project
MVC project knows the concrete repositories types to provide correct container registrations.
You can make life simpler with StructureMap Registry objects but you need to include those Registries somewhere as well. Typically those are in the main project or some "StructureMap-adapter" project but you'd need to make reference anyway.
I'd advise that you:
Use MVC3 and drop your custom IControllerFactory if you only use it for DI into your Controllers.
Use StructureMap Registry objects to provide each and every IoC registration ever needed.
Use StructureMap Assembly scanning capabilities to provide components discovery.
Use something much more common as a DependencyResolver, i.e. not a StructureMapControllerFactory but a CommonServiceLocator with StructureMap adapter instead.
Try to abstract from StructureMap itself inside your main app.
And, of course, don't be afraid of making references inside the main project - they have nothing about coupling. It doesn't decrease maintainability. But the wrong architecture does, so be worried about that, not simple reference.