Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I would like to try using an DI/IoC framework for the first time in a small-ish but growing project, and I don't want to disturb the project much by introducing bulky dependencies. The project itself is partly intended to be used as a library in other projects, and I don't want to trouble users with managing extra dependencies. It's also a matter of taste--I feel the size of a component should be proportional to the amount of services that I actually need. I hate to incorporate a bulky component with dependencies of its own, only to use a small part of it.
So, for .NET, is there a small DI/IoC framework that compiles to a single DLL with no dependencies other than standard libraries, that (if necessary) could be directly embedded in the assembly that uses it, and that emphasizes code-based/fluent (as opposed to XML) wiring? It must not require .NET framework 4.0.
I feel much the same as you do about IOC frameworks. I use IOC all the time, I just don't see the need for a Framework much.
Having said that, the one I'd use if I were to pick one up would be AutoFac
It's simple, easy to grasp, and feels lightweight.
I'd also suggest in addition to NInject that you look at Microsoft's DI Framework, Unity.
Any framework that you will introduce will eventually become a dependency of your app. Also, people have varied definitions of what lightweight is. Take a look at Unity, or StructureMap or Castle Windsor as they tend to be more popular. Scott Hanselman has a whole list, here. Take your pick.
Take a look at Ninject.
Try StructureMap.
The core StructureMap.dll is pretty small.
There are examples on the web about writing your own container, although they are very basic and would lack features provided by a more robust framework.
I work with a rather large system and we've manually injected everything. We make use of the abstract factory pattern to tidy up most of the injection/wiring and it's worked out fine.
DI Frameworks are plentiful. Before taking on an extra external dependency, take some time to consider if applying a different/new pattern would solve your problems.
edit: (possibly biased/unjust) Reasons I haven't used a DI framework:
If you use a DI framework, you have to ship the DI framework with your software. This can be a show stopper for some, and others might have to argue the merits of the extra dependency.
You still have to build constructors to take dependencies
And you still have to tell (or at least hint) at the DI framework what to use. The only major difference is your using the DI factory rather than your own.
As for building that factory, most refactoring tools can do 90% of the work for you with very few keystrokes.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am pretty new to building restful web api's but I have been doing a lot of studying and have a strong understanding of the basics. I have built a service for my company using the latest best practices of web api 2. Attribute routing and route prefixes, dependency injection, and more. I think my service is pretty solid, but there is a possible need of a refactor.
My company is considering moving away from MS SQL to PostGreSql or possibly a different database solution. Also, I should mention that we do not use EF or any other ORM. The reason for us not using EF is because our DB schema is constantly changing and we have numerous environments that are often different from each other(dev, qa, prod, etc). So we have developed our own framework to handle our queries to the databases. We use stored procedures pretty regularly to retrieve data.
So, changing my service to accommodate a different DB, it seems that a repository pattern would be the solution. However, when I start researching into it, it feels like we are adding a lot of overhead code when in fact, it might be less code to write to just go back and refactor the service if the DB change actually happens. For each of my controllers I would need to write a IModelRepository and ModelRepository class at the least.
Can anyone provide any guidance on this?
Edit:
I'm not really sure how to make this question less broad. I don't know enough about repository patterns to be more detailed in my question. I basically, just wanted to know if repository pattern is the solution to the issue of possibly changing DB solutions in the future in a web api MVC service even if I am not using an ORM like entity framework?
I ask because every example I find online seems to use EF which makes it hard to relate to my current issue. However, the top answer gives a really good explanation and I think my question is answered. I just need to find a good resource to learn the pattern from. Thanks.
Repository pattern tries to avoid tight coupling of your domain with data-mapping layer (or just call it data layer), which is occasionally dependent to underlying data technology of choice.
While you might feel that's useless in your concrete use case, I'll try to convince you with a very simple argument: data-access details will be enforced in your repositories and this means that your data strategy will be self-contained there. In other words: your domain will remain agnostic to data-access approach, and you won't need to change thousands and thousands of code lines if you need to change this in the future.
Conclusion: even in your scenario repository pattern is useful. Leave your domain code to just solve domain issues rather than mixing everything in a true spaguetti code!
The inversion of control story...
When repository pattern meets inversion of control everything gets more powerful, since you can switch how your domain translate to data by configuration, and you enforce even more loose coupling and and separation of concerns.
Beat this ;)
Not using EF seems to be the mistake. EF would be the repository that abstracts away the database to a large extent. You want to be able to target different database products. EF is good at that.
Introduce Entity Framework to solve the problem.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is Microsoft working on a solution for AOP in C#? What are the (real AOP) alternatives?
Bonus question: is Code Contracts a kind of AOP?
Most dependency injection frameworks in .net have the ability to use AOP techniques, I personally prefer Ninject and the Interceptor plugin as its simple to use and doesn't require any class pollution with 3rd party attributes or anything.
That being said Spring.net, Castle Windsor and lots of other DI frameworks support the same principle with slightly different syntax and approaches, some are xml driven some are c# driven so you can have compile time safety.
One thing to think about is that most DI frameworks do this via class proxying, so they require your methods to be virtual and then at runtime it proxies your class method and you can intercept at that point. There are some other approaches such as IL weaving which is what PostSharp does, which can be faster than proxying, although I dont have any measurements to back that up.
Didn't see the bonus question bit, for me I would say its not a clear cut answer, as it depends on how you use it, as generally you are using AOP as a way to separate your non functional concerns such as logging, transactions maybe validation from your source code, so you add this logic from the outside in, so ideally your source code has no knowledge of the AOP happening (although that's not always the case if you are using some 3rd party attributes which will couple your source code to the AOP framework).
As code contracts can be written in-line with existing classes or hooked in via attributes or I believe can be fully injected at runtime, so much like logging concerns you could put them all into your classes but when using an AOP approach you wouldn't. So for me Code Contracts are just a tool to enforce something, you can use it in an AOP fashion or you can just embed it in your code.
PostSharp is another alternative. Easy to get started with, although it is no longer free to use fully.
I don't know if Microsoft is still actively contributing to the Unity project. Maybe others can shed some light on this.
Code Contracts is not (a type of) Aspect Oriented Programming.
As alternative you can also use Spring AOP
Link : http://static.springsource.org/spring/docs/2.0.x/reference/aop.html
Nota : I prefer Unity
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Scenario
I have recently graduated from university with a degree in Computer Science.
My degree mainly focused on C#.
I want to learn more and get better at what I do.
I notice a lot of companies always want their developers to know and use 3rd party tools.
Question
If I was developing C# Windows Forms applications, what 3rd party tools/libraries/controls etc. would be of use to me and for what reason?
The answer to this question depends on how you define "3rd party tools". I usually take that to mean products from companies other than MS but excluding free open source software. When it comes to 3rd party products (for-profit) I cannot think of any common products that I've used or been asked to learn over the last decade that I've been doing .Net development. Most MS shops I've worked with turn to MS solutions (for good or ill depending on your personal view).
That said, in recent years the number and quality of the various FOSS solutions out there has risen dramatically. I use the following whenever I can:
Logging: log4net
Inversion of Control Container (plus more): Castle Windsor
ORM: NHibernate
Unit Testing: NUnit
Mocks for unit testing: Rhino Mocks
For most of these projects there are many other options, these are just my current favorites. Learn to use these (and WHY they are needed) and you'll be many steps above the average .Net developer (sad but all to true).
The DevExpress and Telerik controls are pretty popular, but not free.
Some 3rd party .Net component providers that I've seen used in companies most often:
Telerik
Infragistics
They are not free. These kinds of providers offer large libraries of controls that you'd pick from to achieve your specific goals.
Many good suggestions here, I would also add a few other categories of tools:
Software configuration management/version control: CVS, Subversion, Git/Mercurial/Bazaar, Perforce, etc. Good use of SCM is essential for professional software development.
Issue tracking: Bugzilla, Trac, FogBugz, etc. I would also consider an issue tracking system to be a critical piece of software.
Documentation: Like it or not, it becomes very handy to know your way around Microsoft Word. Knowing how to manipulate styles, headings, numberings, cross-references, etc. can make your life a lot easier when writing documentation.
You'd probably want to have a look at Silverlight. It's a Microsoft alternative to Flash and uses C#. WPF are also something to look at for interfacing.
It might also be worthwhile looking at MOSS.
I've always liked the Xceed controls. In a lot of cases you could always build your own controls. The biggest advantage to using some of these packages is that it saves you the time and they have also been well tested (if not by the company then by the people that are using them).
I've used a couple of different packages over the years and found that if you can use one it's not that hard to use another. The biggest thing is knowing what is available out there so you don't spend two weeks building something that you could have just paid a few hundred dollars for.
You should know about resharper (helper for VS)
Crystal reports - for reports,
Some Grid tools (google it, there are many - I wouldn't bother to learn until need one)
and study advanced topics like: WCF, WPF
Cruise control or other building tool, bugnet or trac - bug management tools...
And of course - AQtime or other Profiling tools.
.NET Reflector
Hawkeye - The .Net Runtime Object Editor
Infragistics
I'd throw mono in there as well. Since you're looking to give yourself an advantage over other developers and improve your value to companies - having cross platform experience is advantageous as well.
There are a lot of 3rd party controls that will help you achieve more in less time. But I don't think many of them will really improve your coding skills (calling someone else to do all the work doesn't teach you much about how to actually do thise things yourself, but familiarity with them and the ability to learn new libraries is a good skill to practice)
Resharper is good for improving your coding skills (code analysis), coding style (autoformatting), and it's a great refactoring tool. It's expensive, though.
Microsoft do some free code analysis tools for Visual Studio (FXCop for code analysis, and there is also a Static Analysis addin) which will help improve your code quality.
AtomineerUtils (my own addin) encourages excellence in documentation and generally improves your code quality (by encouraging good naming style, etc)
Focus more on the tools used in the software development process. Enterprise Architect is used for designing applications from a high level. Once you design you application's business classes you can generate your classes' skeletons. You will be responsible for you code implementation once the class structure has been created.
For implementation purposes look at several C# platforms mentioned earlier. You want to focus Microsoft's WPF, WCF, WF. WPF is ok but it can not be used prior to .net 3.0 so check your client's requirements. I'm working on a project that targets the .net 2.0 because of restrictions by the client so the applicaiton was designed in WinForms. Silverlight is an option as well.
In addition, read up on design patterns as this will help you avoid creating high maintenance applications. A good book is Design Patterns in C#.
For testing look at the Visual Studio TFS system or third party programs like NUnit. You can google NUnit. This will help you ensure that your code does what you intended it to do on a granular scale.
Also, take a look at some of the source control software avaialbel like Subversion, Rational ClearCase, Visual SourceSafe. For large projects with multiple developers you'll need a source control tool that has multiple branches so that each developer has his or her own sandbox within the source control system.
I'm a big proponent of ComponentOne and use it in my new applications regularly. I find that if you're proficient in .NET winforms in general, C1 are very easy to pick up on and usually do what you want with little effort.
A couple people mentioned Telerik. I demoed it fairly extensively and found them to be a bit more complicated because they contain a ton of configuration options for look and feel. Awesome if you're some sort of graphic designer, but unless you're building the next Windows Media Player, I think it's overkill. The learning curve for the theming seemed a bit much for what I was trying to accomplish.
C1 and Telerik both run about $1000 to $1300 depending on what license you get.
You should also check out the Krypton toolkit. It free and has a lot of nice controls.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
(subjective)
I'm looking for what your using to perform logging in your application. This log4net thing is giving me headaches. Is there a better answer out there or is everone just homebrewing a solution? I know the System.Diagnostics.Trace subsystem is quite capable should I layer on this?
NLog is probably the other big player in this area. Also, There is an application bloc in entreprise library that is dedicated to tracing and logging.
Why not use just the .NET classes for logging?
With Custom-Listeners you can do almost anything for logging, can apply filters, spread your logs to multiple targets, databases, files, network, whatever.
Just watch out what the .NET-Framework is capable of, you'll be surprised.
There are quite a few .NET logging libraries and tools out there, here's an extensive list:
http://www.dotnetlogging.com/
You might also want to take a look at our .NET logging product SmartInspect, which provides rich logging capabilities (in contrast to the text-only logging features of most other logging tools) and comes with a log viewer and optional log server application.
Try Elmah its pretty easy, mind you log4net is not so bad once you get your head into it....
What actually are your headaches?
We use the Enterprise Library exclusively in our corporate environment (Logging Block). And I've recently started to use Log4Net on personal projects.
From experience, the Enterprise Library, albeit powerful, is a mighty pain to get up and running. Not only from just trying to figure out which dll's to use, but the configuration can become unwieldy.
On the flip side, I've found Log4Net to be extremely easy and you can be up and running in no time; quite literally in less than an hour.
Granted I'm a MS fanboy (ok, not really, but they are the reason I can make a living) and typically go with MS. However, I've made the recommendation to migrate to Log4Net at work. The simplicity of it really is refreshing.
Take a look at Common.Logging. It works with all major logging frameworks (system.diagnostics, log4net, nlog, entreprise library) and allows you to switch logging frameworks from configuration.
From my personal experience - I've used .NET tracing in a corporate environment which didn't allow us to use opensource, and after we perfected the rolling file tracelistener, it was quite easy to use. Now I use log4net and it's pretty nice, but takes some getting used to.
I know this question is too old and you are looking for alternative to log4net, but believe me log4net is the best logging solution and is most commonly used and also provides large range of log listeners than any other logging framework. Moreover you can even implement a custom appender along with the in-built appenders. For those who are having trouble configuring log4net can use following post which describes step by step guide to make it work.
Log4Net section in Web.Config generates Error
happy logging:)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which C#/.NET Dependency Injection frameworks are worth looking into?
And what can you say about their complexity and speed.
edit (not by the author): There is a comprehensive list of IoC frameworks available at https://github.com/quozd/awesome-dotnet/blob/master/README.md#ioc:
Castle Windsor - Castle Windsor is best of breed, mature Inversion of Control container available for .NET and Silverlight
Unity - Lightweight extensible dependency injection container with support for constructor, property, and method call injection
Autofac - An addictive .NET IoC container
DryIoc - Simple, fast all fully featured IoC container.
Ninject - The ninja of .NET dependency injectors
Spring.Net - Spring.NET is an open source application framework that makes building enterprise .NET applications easier
Lamar - A fast IoC container heavily optimized for usage within ASP.NET Core and other .NET server side applications.
LightInject - A ultra lightweight IoC container
Simple Injector - Simple Injector is an easy-to-use Dependency Injection (DI) library for .NET 4+ that supports Silverlight 4+, Windows Phone 8, Windows 8 including Universal apps and Mono.
Microsoft.Extensions.DependencyInjection - The default IoC container for ASP.NET Core applications.
Scrutor - Assembly scanning extensions for Microsoft.Extensions.DependencyInjection.
VS MEF - Managed Extensibility Framework (MEF) implementation used by Visual Studio.
TinyIoC - An easy to use, hassle free, Inversion of Control Container for small projects, libraries and beginners alike.
Stashbox - A lightweight, fast and portable dependency injection framework for .NET based solutions.
Original answer follows.
I suppose I might be being a bit picky here but it's important to note that DI (Dependency Injection) is a programming pattern and is facilitated by, but does not require, an IoC (Inversion of Control) framework. IoC frameworks just make DI much easier and they provide a host of other benefits over and above DI.
That being said, I'm sure that's what you were asking. About IoC Frameworks; I used to use Spring.Net and CastleWindsor a lot, but the real pain in the behind was all that pesky XML config you had to write! They're pretty much all moving this way now, so I have been using StructureMap for the last year or so, and since it has moved to a fluent config using strongly typed generics and a registry, my pain barrier in using IoC has dropped to below zero! I get an absolute kick out of knowing now that my IoC config is checked at compile-time (for the most part) and I have had nothing but joy with StructureMap and its speed. I won't say that the others were slow at runtime, but they were more difficult for me to setup and frustration often won the day.
Update
I've been using Ninject on my latest project and it has been an absolute pleasure to use. Words fail me a bit here, but (as we say in the UK) this framework is 'the Dogs'. I would highly recommend it for any green fields projects where you want to be up and running quickly. I got all I needed from a fantastic set of Ninject screencasts by Justin Etheredge. I can't see that retro-fitting Ninject into existing code being a problem at all, but then the same could be said of StructureMap in my experience. It'll be a tough choice going forward between those two, but I'd rather have competition than stagnation and there's a decent amount of healthy competition out there.
Other IoC screencasts can also be found here on Dimecasts.
It depends on what you are looking for, as they each have their pros and cons.
Spring.NET is the most mature as it comes out of Spring from the Java world. Spring has a very rich set of framework libraries that extend it to support Web, Windows, etc.
Castle Windsor is one of the most widely used in the .NET platform and has the largest ecosystem, is highly configurable / extensible, has custom lifetime management, AOP support, has inherent NHibernate support and is an all around awesome container. Windsor is part of an entire stack which includes Monorail, Active Record, etc. NHibernate itself builds on top of Windsor.
Structure Map has very rich and fine grained configuration through an internal DSL.
Autofac is an IoC container of the new age with all of it's inherent functional programming support. It also takes a different approach on managing lifetime than the others. Autofac is still very new, but it pushes the bar on what is possible with IoC.
Ninject I have heard is more bare bones with a less is more approach (heard not experienced).
The biggest discriminator of Unity is: it's from and supported by Microsoft (p&p). Unity has very good performance, and great documentation. It is also highly configurable. It doesn't have all the bells and whistles of say Castle / Structure Map.
So in summary, it really depends on what is important to you. I would agree with others on going and evaluating and seeing which one fits. The nice thing is you have a nice selection of donuts rather than just having to have a jelly one.
Autofac. https://github.com/autofac/Autofac It is really fast and pretty good. Here is a link with comparisons (made after Ninject fixed a memory leak issue).
http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html
Ninject is great. It seems really fast, but I haven't done any comparisons. I know Nate, the author, did some comparisons between Ninject and other DI frameworks and is looking for more ways to improve the speed of Ninject.
I've heard lots of people I respect say good things about StructureMap and CastleWindsor. Those, in my mind, are the big three to look at right now.
I use Simple Injector:
Simple Injector is an easy, flexible and fast dependency injection library that uses best practice to guide your solutions toward the pit of success.
I'm a huge fan of Castle. I love the facilities it also provides beyond the IoC Container story. It really simplfies using NHibernate, logging, AOP, etc. I also use Binsor for configuration with Boo and have really fallen in love with Boo as a language because of it.
I spent the better part of a day struggling without success to get the simplest Spring.NET example working. Could never figure out how to get it to find my assembly from the XML file. In about 2 hours, on the other hand, I was able to get Ninject working, including testing integration with both NUnit and MSTest.
I've used Spring.NET in the past and had great success with it. I never noticed any substantial overhead with it, though the project we used it on was fairly heavy on its own. It only took a little time reading through the documentation to get it set up.
I can recommend Ninject. It's incredibly fast and easy to use but only if you don't need XML configuration, else you should use Windsor.
The great thing about C# is that it is following a path beaten by years of Java developers before it. So, my advice, generally speaking when looking for tools of this nature, is to look for the solid Java answer and see if there exists a .NET adaptation yet.
So when it comes to DI (and there are so many options out there, this really is a matter of taste) is Spring.NET. Additionally, it's always wise to research the people behind projects. I have no issue suggesting SourceGear products for source control (outside of using them) because I have respect for Eric Sink. I have seen Mark Pollack speak and what can I say, the guy just gets it.
In the end, there are a lot of DI frameworks and your best bet is to do some sample projects with a few of them and make an educated choice.
Good luck!
I think a good place to start is with Ninject, it is new and has taken into account alot of fine tuning and is really fast. Nate, the developer, really has a great site and great support.
Spring.Net is quite solid, but the documentation took some time to wade through. Autofac is good, and while .Net 2.0 is supported, you need VS 2008 to compile it, or else use the command line to build your app.