Code == Data
- Dynamically modify code at run time.
- Create new code at run time.
- Translate code to another Langauge (SQL, XPath, etc.)
- Strongly typed.
Expression<Func<string, bool>> expression = x => x == "Value"; var x = Expresion.Parameter(typeof(string), "x"); Expression<Func<string, bool>> expression = Expression.Lambda<Func<string, bool>>( body: Expression.Equal( left: x, right: Expression.Constant("Value")), parameters: x);
- Easier to read
- Don’t need to learn the API
- Compiler will simplify constant expressions
- Additional commands available
- Dynamically create expression trees
Expression Trees are Immutable – you cannot change them at runtime.
Most C# programmers use expression trees all of the time without even knowing it. For example, LINQ syntax uses expression trees. Func<T, bool>
Expression trees are not useful for just querying. It also has it’s uses for what is called Fluent Configuration. The logic is that is is much better to get configuration errors at compile time rather than runtime. (Don’t know if I’m in agreement with this – I prefer web.config files for configuration changes. They recycle and restart your app when you change them. You also don’t need to recompile your code to change a configuration.)
Source code for presentation at: http://chadkulesa.com
How to extend .NET Applications with MEF plugins. Not how to create METH-amphetamines.
Why should we bother using an extensible architecture? The dominant reason is that the decision of what code to run is not known at compile time. The classic sign that you should be using a plugin based architecture is that you are using a switch statement with a ton of cases. Another, is if you have an app that needs to act differently depending on what kind of record it is in the context of. If the context matters as to what code you want to run. Another great reason is if you want other developers to build upon your product.
The reason the Microsoft focus is on MEF is because Visual Studio’s plug architecture is all MEF based as of 2010.
"I need a" = "Import"
"I need some" = "Import Many"
"I have a" or "I am a" = "Export"
"Match up the needs with the providers" = "Compose"
Source code dealt with a loan processing company that did just that – processed loans – console app.
Loan processors became Interfaces injected into the LoanApplication so that many types of Loan Processors can be defined.
Morphed app to use DI/IoC to import the needed LoanProcessor.
Usually, he creates a default implementation of an Export in the assembly so his app does not throw exceptions if there are no imports/exports found. Because of this, he always includes an AssemblyCatalog in the final composition catalog that contains the executing assembly. J calls this Plugin selection with fallback.
Showed an awesome way to load modules. He usually uses the ImportMany attribute to import everything and let the application choose how to load the modules. His example had a method called ChoosePlugins.
caveat. Metro apps IoC containers only work with MEF.
Source available here.
check out if this then that