I see parallels between MEF and Lua. Both allow you to register methods and deploy as you need. Are both MEF and Lua forms of IoC / Dependency Injection?
I'll assume you're aware of the huge differences between these technologies and focus on the question:
"Are both MEF and Lua forms of IoC /
Dependency Injection?"
Also, I'll assume you're talking about embedded Lua versus Lua as a language.
First, let's separate Dependency Injection from Inversion of Control. Fowler defined Dependency Injection as a specific form of IoC because the idea of IoC had become so common that it was no longer a distinguishing characteristic of a system. His definition includes three main types of Dependency Injection: Constructor injection, Setter injection, and Interface injection. In all three types, the idea is to inject a specific implementation of a class or interface into a class or method that needs it. This is pretty slick because it allows you to decouple the dependency and the class that uses it. As long as they follow a contract, you can edit and swap implementations of the dependency without its consumers caring or being effected.
Using this definition, I'd say MEF passes and embedded Lua fails. MEF is largely a dependency injection framework. It allows you to dynamically load and compose external classes that implement specific contracts. Lua, on the other hand, allows extension through scripting but there is very little in the way of a contract. Sure, you could provide a Lua API for your app and that's a contract of sorts, but it does nothing to ensure a true contract is honored.
IoC is broader.(Fowler,Wikipedia) The common theme is that main program flow gives up control temporarily but receives flow status updates from components that are doing the work. Common ways to accomplish this include: events, closures, and continuations.
Using this definition, MEF easily passes (control is passed to unknown components at runtime) and you can make an argument for embedded Lua as well. The main program cruises along until it needs a function defined in external script. At that point, control is delivered to the script until it's done or is interrupted.
One thing to note is that Lua isn't particularly special in this regard. You can embed Perl, Python, Tcl, and Ruby. In fact, the general definition of IoC isn't particularly useful in a modern programming environment. It's too common. Fowler says that's why he introduced Dependency Injection as a special case. In a world of GUIs, events, threads, daemons, closures, continuations, and monads, everything uses IoC. Today, when people say 'IoC', they often mean some sort of Dependency Injection.
MEF has nothing to do with Lua, and is nothing like Lua.
MEF is a framework for extending (basically, an awesome plugin framework).
Lua is a very cool scripting language.
"Both allow you to register methods and deploy as you need." That sentence applies to C, C++, C#, VB, SQL, DI Frameworks, JavaScript, General Motors, Ford, Hospitals...
Related
first, I'm new to the software world. so my apologies if this is a simple or bad question.
I've been reading about DI and IOC and I understood DI is one way of achieving IOC ( there are other ways as well). so it kept me thinking, does DI always result in Inversion of Control? does it depend on how you call the methods or classes that benefit from DI? in other words, the flow of your application will decide whether or not DI will result in IOC, is this right?
I think this quote from Dependency Injection Principles, Practices, and Patterns (DIPP&P) pretty much sums it up:
Dependency Injection or Inversion of Control?
The term Inversion of Control originally meant any sort of programming style where an overall framework or runtime controlled the program flow. According to that definition, most software developed on the .NET Framework uses IoC. When you write an ASP.NET Core MVC application, for instance, you create controller classes with action methods, but it’s ASP.NET Core that will be calling your action methods. This means you aren’t in control — the framework is.
These days, we’re so used to working with frameworks that we don’t consider this to be special, but it’s a different model from being in full control of your code. This can still happen for a .NET application, most notably for command-line executables. As soon as Main is invoked, your code is in full control. It controls program flow, lifetime — everything. No special events are being raised and no overridden members are being invoked.
Before DI had a name, people started to refer to libraries that manage Dependencies as Inversion of Control Containers, and soon, the meaning of IoC gradually drifted towards that particular meaning: Inversion of Control over Dependencies. Always the taxonomist, Martin Fowler introduced the term Dependency Injection to specifically refer to IoC in the context of dependency management. Dependency Injection has since been widely accepted as the most correct terminology. In short, IoC is a much broader term that includes, but isn’t limited to, DI.
[source: Section 1.4.1, page 29. Online version]
This quote is written in the context of .NET, but if you filter out the .NET and ASP.NET, it is applicable broadly. In Martin Fowler's original definition, IoC was about frameworks, while DI in itself can be applied without any frameworks, for instance using 'simple' (UI-less) Console applications. This means that, from Fowler's original definition, it is possible to practice DI without applying IoC.
Over the years the term IoC, however, has "drifted" and we now generally see DI as as specialized form of IoC. A "sub type" or "implementation" so to speak, where IoC is the concept or "abstraction." This means that you can't apply DI without IoC, because practicing DI means practicing IoC. You can, however, practice IoC, without practicing DI as there are other IoC implementations, such as Service Locator.
I am confused about this line
Aspect-Oriented Programming and Dependency Injection are very different concepts, but there are limited cases where they fit well together.
from this website
http://www.postsharp.net/blog/post/Aspect-Oriented-Programming-vs-Dependency-Injection
I understand the advantages of DI over AOP, but why aren't they used together more often? why are there only limited cases where they fit together? Is it because of the way AOP is compiled, that makes using both difficult?
How do you define "limited cases"? I myself always use AOP and DI together.
There are basically three ways to apply AOP, which are:
Using code weaving tools such as PostSharp.
Using dynamic interception tools such as Castle Dynamic Proxy.
Using decorators.
The use of DI with code weaving tools doesn't mix and match very well, and I think that's the reason that the Postsharp site states that "there are limited cases where they fit well together". One reason it doesn't mix and match is because Dependency Injection is about loose coupling, while code weaving hard couples your code and the aspects together at compile time. From a perspective of DI, code weaving becomes an anti-pattern. In section 11.2 of our book, Mark and I make this argument very clear. In summary we state:
The aim of DI is to manage Volatile Dependencies by introducing Seams into your application. Theis enables you to centralize the composition of your object graphs inside the Composition Root.
This is the complete opposite of hat you achieve when applying compile-time weaving: is causes Volatile Dependencies to be coupled to your code at compile-time. This makes it impossible to use proper DI techniques and to safely compose complete object graphs in the application's Composition Root. It's for this reason that we say that compile-time weaving is the opposite of DI–using compile-time weaving on Volatile Dependencies is an anti-pattern. [page 355]
If you use dynamic interception, however, which means applying cross-cutting concerns at runtime by generating decorators on the fly it works great with DI and it is integrated easily with most DI libraries out there, and can be done as well when using Pure DI, which is something we demonstrate in section 11.1.
My personal preference is to use decorators. My systems are designed around a few well defined generic abstractions, and this allows me to apply cross-cutting concerns at almost all places that are important to my system. That leaves me in very rare cases with a few spots where decorators don't work very well, but this is almost always caused by design flaws. Either by my own limitations as a developer or by design flaws in the .NET framework or some other tool. One famous design flaw is the INotifyPropertyChanged interface. You might have guessed it, but in our book we describe this method in a lot of detail. We spend a complete chapter (10) on this topic.
I've read a number of threads explaining the difference between IoC and DI and while many of explanations contradicted each other, I think they still helped me understand the difference.
So here I'd like to ask whether my understanding is correct and also post excerpts that helped me ( though some of them contradict each other ).
I know there have been lots of threads done on the subject, but I'm hoping this thread won't get closed since I don't think any of OPs in mentioned threads also showed all the relevant posts ( from various threads ) that helped them finally understand it.
Anyways, here is how I understand it (if possible,please address/answer each question individually ):
a) When we apply DIP principle at the framework level, then we use the term IoC? And one of the mechanisms to implement DIP at framework level is DI?
b) The term IoC does not apply when we implement DIP ( using DI ) at a lower level/non-framework level, in which case we simply call it DI?
c) DI helps us to achive DIP by passing the control of the actual creation of and selection of dependencies to a 3rd party which is neutral to either of the other 2 involved?
d) When DIP is applied ( using DI ) at framework level (IoC), then three types of control get inverted:
The control of the interface. Now high level module is controlling the interface that the lower level modules need to adhere to instead of the other way around
The control of the flow. --> Now framework code ( instead of user/business code ) controls the flow of the program ( in other words - they ( ie framework ) call you ( ie business code ) )
The control of dependency creation. This inversion is passing the control of the actual creation and selection of dependencies to a 3rd party which is neutral to either of the other 2 involved.
e) When DIP is applied (using DI) at non-framework level, then two types of control get inverted:
The control of the interface. Now high level module is controlling the interface that the lower level modules need to adhere to instead of the other way around
The control of dependency creation. This inversion is passing the control of the actual creation and selection of dependencies to a 3rd party which is neutral to either of the other 2 involved.
?
Here are excerpts that helped:
Why so many terms to say the same thing? IoC and DIP
Inversion of Control is the generic term. Dependency Injection is a
specific type of IoC
...
Inversion of Control is when the framework/infrastructure invokes
application code, rather than the other way around
...
can do DI without doing IoC. If you inject aConsoleStringWriter into a
HelloWorld I don't really think of this as IoC because there is no
"framework" or "infrastructure".
Inversion of Control < Dependency Injection
If you accept Fowler's definition, Inversion of Control is a much
broader term than DI that covers allframework usage where you plug
into a framework, but the framework is still in control. Dependency
Injection is a specialization of IoC that applies IoC specifically to
manage dependencies.
Where exactly is the difference between IoC and DI
IoC is the ability to vary the implementation of a contract. DI is the
ability to supply the implementation.
...
In traditional applications, developers would write business code and
framework code. The business code would then call the framework code
to accomplish tasks. Under an IoC model, you "invert" that model and
create a framework that accepts business modules and calls them to
accomplish tasks
Dependency Injection is a technique (hard to call it a pattern,
really) of removing internal dependencies from implementations by
allowing dependent objects to be injected into the class/method by an
external caller. IoC frameworks use dependency injection to supply
user modules and other dependent code to framework routines that "glue
it all together." Dependency injection is used heavily by IoC
frameworks because that is the mechanism that allows them to "Call
You."
DIP vs. DI vs. IoC
DIP is the principle that guides us towards DI. Basically, loose
coupling is the goal, and there are at least two ways to achieve it.
• Dependency Injection • Service Locator
Does anyone have a good analogy for dependency injection?
The essence of Inversion of Control (of which Dependency Injection is
an implementation) is the separation of the use of an object from the
management thereof.
Difference between ioc and dependency injection
The terms Dependency Injection (DI) & Inversion of Control (IoC) are
generally used interchangeably to describe the same design pattern
(although not everyone agrees on that point, and some people tend to
apply them in slightly different ways). The pattern was originally
called IoC, but Martin Fowler proposed the shift to DI because all
frameworks invert control in some way and he wanted to be more
specific about which aspect of control was being inverted.
Inversion of Control vs Dependency Injection
Inversion of Control (IoC) means that objects do not create other
objects on which they rely to do their work. Instead, they get the
objects that they need from an outside source (for example, an xml
configuration file). Dependency Injection (DI) means that this is done
without the object intervention, usually by a framework component that
passes constructor parameters and set properties.
thank you
Well this is my point of view:
DIP means that you program against an abstraction. You invert the kind of a dependency from an implementation to an abstraction.
IOC means that somebody else is responsible for getting the implementation for the given abstraction. Normally the consumer would use the new keyword to get a dependency. With IoC you invert the control, so that the consumer is not responsible for creating the instance anymore.
Dependency Injection and Service Location are a part of Inversion of Control.
See also: https://stackoverflow.com/a/10053413/175399
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Inversion of Control < Dependency Injection
I always read IoC(Inversion of Control) and DI(Dependency Injection) in the same context. What is exactly the difference between IoC and DI? How does IoC differ from DI?
In common usage, the terms have become somewhat synonymous. The original idea of IoC -- Inversion of Control -- was very much related to the "Hollywood Principle:" Don't Call Us, We'll Call You.
In traditional applications, developers would write business code and framework code. The business code would then call the framework code to accomplish tasks. Under an IoC model, you "invert" that model and create a framework that accepts business modules and calls them to accomplish tasks. This principle is exhibited in several development frameworks including the old Smart Client Software Factory and the newer Prism (or Composite Applications for WPF/Silverlight). In these models, the UI Modules are registered with an IoC Container and loaded as needed based on configuration and user actions. While powerful, these models also tend to have a very steep learning curve.
Dependency Injection is a technique (hard to call it a pattern, really) of removing internal dependencies from implementations by allowing dependent objects to be injected into the class/method by an external caller. IoC frameworks use dependency injection to supply user modules and other dependent code to framework routines that "glue it all together." Dependency injection is used heavily by IoC frameworks because that is the mechanism that allows them to "Call You."
IoC Containers, such as Castle Windsor and Structure Map help with dependency injection by providing automatic instantiation and lifecycle management of classes you register -- including automatic instantiation and injection of parameters required by registered classes. All of this makes it easier to use dependency injection, but is not required.
Dependency Injection is a mechanism for flexibility that maximizes dependency on Interfaces while minimizing dependency on specific implementation. Consequently, systems that use dependency injection can support "pluggable" implementation classes that can be used depending on circumstances. A very big benefit of this "pluggability" is that it makes creating Unit Tests much easier. You can mock an object to the needed interface, then inject it into your test object.
So, IoC is really the broader principle and DI is a fundamental technique within. IoC (Hollywood Principle) systems tend to be pretty complex, can be hard to understand, and thus have steep learning curves. DI, on the other hand is a good practice for everyday developers. I tend to prefer understandable and clear over cool, but complex.
IoC is the ability to vary the implementation of a contract.
DI is the ability to supply the implementation.
DI/IOC: There are so many frameworks and the examples quickly get sticky with details particular to that framework. I find that I often learn a new technology best if I can learn its principles outside of a framework (the forest obscuring the trees).
My question: What are the simple principles of DI/IOC? I am looking for a (framework agnostic) building approach that outlines what is gained, what the options are, what the costs are, for each simple principle. Please don't just paste links unless they actually address my question. I keep getting lost in those forests ;}
Second question: Once I understand the core principles, would it be worth building my own simple framework? IE, would the insight gained be valuable relative to the effort expended?
Thanks in advance!
Robert
My very quick and dirty take on it
Dependency Injection and Inversion of Control are not the same thing. Inversion of Control uses DI.
IoC is a way of snapping your application together at run time rather than compile time.
Instead of 'newing up' a type in the code, it is injected at run time by the IoC container.
The IoC container knows what to inject into your class because a) It looks at the constructor of that class - all the parameters are interfaces. b) It looks at its configuration file and sees what classes that implement each interface you have chosen to represent that interface in your application.
Here's a very basic example
Let's say you have an interface IEmailer for sending emails:
public interface IEmailer
{
void SendEmail();
}
And you have at least one implementation of this interface:
public class IainsEmailer : IEmailer
{
public void SendEmail()
{
// Send email
}
}
You define in IoC container's config file (somehow):
IainsEmailer is my choice for IEmailer
Then in your code you can have the following and the IoC container will inject an IainsEmailer into any constructor that needs an IEmailer.
public class MyClass
{
private IEmailer _emailer;
public MyClass(IEmailer emailer)
{
_emailer = emailer
}
// You can now use emailer as if you have created it
_emailer.SendEmail();
}
I could go on. And on. But this really is the whole idea of IoC in a nutshell.
This is a somewhat dated but good overview Inversion of Control
To me the underlying principles that drive Ioc are the concepts of components, modularity, loose coupling, cohesion. This means that you design software that is broken up into cohesive, modular units with clear dependencies, or links to other units. This is a basic principle of engineering in any field, not just programming. Once you have modularity, to create a functional system you need a way to link these components so that they form a functional whole. IoC/DI frameworks are components that abstract this concept of linking, and allow you to write code that declares links between components, and then have the ability to execute these links. The "inversion" part comes from the fact that the components themselves no longer link to their dependencies, instead the linking is performed outside, by a linking component. This in turn, is called dependency injection. A typical IoC/DI framework allows you to write code that specifies a particular implementation of an interface that another component depends on, then allows you to instantiate that component and upon creation, the required implementation will be provided by the IoC container. This then abstracts the concept of object creation.
Your questions warrant a fully fledged Wikipedia article. I assume you've already read up on the actual article so here's my shorter take on your question: Dependency Injection is all about instantiation.
The main idea is that classes should not be responsible for instantiating their dependencies. The DI framework takes over instantiation because it can do it flexibly, via a configuration mechanism that is (typically) external to your code.
This enables you to write classes that are:
Decoupled from their dependencies.
Better focused on their actual responsibility (rather than on their dependencies)
Can be changed through configuration without the need for recompilation.
More easily testable.
Arguably, better designed.
To answer your second question: if you're trying to learn about DI then writing a framework yourself is clearly overkill. I would recommend that you choose one of the popular open source frameworks and write code that consumes it - most have good tutorials just for that purpose.
Taking it to the next level you can take the source code of the framework you were using and start digging into it. The good framework are very well written and relatively easy to read.
Good Luck!
urig
PS - If you're in .net, don't start with MEF. Start with Windsor, Unity or Spring.Net. MEF is both more and less than a DI framework so leave it for a little later.