With NInject (preferably 2.0), what options do we have wrt wiring up our object dependencies in a web application?
Can they be defined in an XML configuration file?
Or does it have to be done via code?
There is an extension for xml based configuration: https://github.com/ninject/ninject.extensions.xml
You can do a lot more powerful binding in code though.
Ninject doesn't have XML configuration, sorry but I can't provide a direct link (cos their site has flash elements), but here is a quotation from ninject.org:
Free yourself from XML
Most other .NET dependency injection
frameworks are designed around the use
of XML to declare type bindings.
Rather than forcing you to write
cumbersome and error-prone text,
Ninject arms you with a fluent
interface, which lets you connect the
pieces of your application using
full-fledged code. This means you can
take advantage of the features of the
IDE and compiler, like code completion
and type-safety.
The problem I see with defining bindings in the code only is that you have to add reference to the dll.
You cannot change the binding without adding reference to new dll (removing reference to old one), change code and recompile.
If we had xml config I wouldn't need reference at all, and wouldn't have to recompile.
Right now I have MVC app that is using DI to pass repositories to Controllers. Nothing else then Ninject code for adding bindings uses the concrete implementations of repositories. And still I need to add reference to dll containing the implementations. For only one line of code!
Or maybe there is a possibility to achieve this using Ninject?
What are you looking to achieve? What sort of stuff are you looking to configure? Dynamically selecting a Strategy ? Passing in Port numbers? You could offer a lot more information as to what you're thinking in order to get a better answer [that you can acccept :P].
You need to split the concerns of:
known object wiring (DI)
configuration - generally you'll want to split those into small focused subsets e.g. Strongly Typed config elements vs having a global pool of settings in a big pile mishmashed together a la appSettings
plugins / unknown object wiring (MEF?)
In the first pool, doing it in Code is just the right way and I cant think of any advantage XML would give, esp. in the context of strong names etc.
Related
I have a flex application which contains different feature that includes google maps, twitter, facebook etc.
Currently I have hardcoded api keys in the code it self but I want to use a properties file/config file where I can put such things and use anywhere I want in the application.
Is it possible to achieve this in flex?
I am using swiz framework. Is it possible to achieve this using this framework?
Thanks
Priyank
We use an external xml config file chock full of config settings for dev, staging, and production environments. Load it into your app at application complete and parse the xml nodes into a value object and store it in your model.
Jeff
ReUrgency.com
if you require LOCAL CONFIGURATION (the configuration specific for each client) then the easiest way to do in flex/air application is using sharedobject because filereference has been limited only for air application. ticlib has an easy and natural way to do local configuration, you only need to add [Config] annotation on your variable or getter then you event don't need to care about how to create and manage shared object. you can take a look at this blog post for real time use.
The Swiz Example Applications have many good examples of this. Look for anywhere they are loading a service config. I believe SwizDemoApp has an example of this, or it could be SwizPresentationModelExample (those were the two I looked at, and one of them had the method I use in my Swiz apps now). :)
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
Project.Domain
Project.Persistence.Implementation
Project.Services.Implementation
Project.DIInjectionRegistration
Project.ASPNetMVCFrontEnd (I use MVC, but it doesn't matter).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.
What are the benefits of Spring Actionscript considering Dynamic Proxies are not possible in the current version of Actionscript and Reflection is quite limited.
So for example I could specify my object creation in an XML application context, but why would I do that when I can simply specify that in code, and hence take advantage of static type checking etc.
It is by no means my intent to belittle the work done on Spring Actionscript but more to find an application for it in my projects.
Besides XML configuration, Spring ActionScript also supports MXML configuration. The type of config (XML, MXML) depends on the use cases your application needs to support. For the reasons you mention, it makes perfect sense to configure most of the context in MXML, but I would encourage you to externalize the config of service endpoints in every case.
In a past project we opted for XML config since the configuration was generated at runtime when a user logged on to the application. Depending on the user credentials, different endpoints and various different settings were used. We could not have done this elegantly with static MXML configs.
Both config types have their strengths and weaknesses, and it's up to you to decide what type you want to use. I think we could even support a mixture of MXML and XML quite easily actually if that would make sense. As soon as we have Dynamic Proxies and class loading, XML config will make a lot more sense.
I would agree with Sean in the general sense that trying to force Flex inside of the Java box is generally a bad idea. As many similarities as there are, Flex is not Java.
That being said, there are plenty of reasons why you might want to have some of your configuration in an external XML file, not the least of which is in the use case of configuring your service destinations and endpoints, where you may have a need to be able to change the endpoint URI without having to recompile your application.
There are several projects available that are simply misguided ports of philosophies from other platforms. Whenever starting in on a new platform, I think the best thing to do is figure out how people are effectively developing and go from there.
I say all of that because I think all of the java-esque frameworks for flex/flash leave you worse off than you started. You do need dependency injection, but there are good as3/mxml-friendly frameworks for that (Mate, Swiz). There is absolutely no point in using xml when you can use mxml, which is strongly typed.
I want to isolate all my code from the IoC container library that I have chosen (Unity). To do so, I created an IContainer interface that exposes Register() and Resolve(). I created a class called UnityContainerAdapter that implements IContainer and that wraps the real container. So only the assembly where UnityContainerAdapter is defined knows about the Unity library.
I have a leak in my isolation thought. Unity searches for attributes on a type's members to know where to inject the dependencies. Most IoC libraries I have seen also support that. The problem I have is that I want to use that feature but I don’t want my classes to have a dependency on the Unity specific attribute.
Do you have any suggestions on how to resolve this issue?
Ideally I would create my own [Dependency] attribute and use that one in my code. But I would need to tell the real container the search for my attribute instead of its own.
Check out the Common Service Locator project:
The Common Service Locator library
contains a shared interface for
service location which application and
framework developers can reference.
The library provides an abstraction
over IoC containers and service
locators. Using the library allows an
application to indirectly access the
capabilities without relying on hard
references. The hope is that using
this library, third-party applications
and frameworks can begin to leverage
IoC/Service Location without tying
themselves down to a specific
implementation.
Edit: This doesn't appear to solve your desire to use attribute-based declaration of dependency injection. You can either choose not to use it, or find a way to abstract the attributes to multiple injection libraries (like you mentioned).
That is the basic problem with declarative interfaces -- they are tied to a particular implementation.
Personally, I stick to constructor injection so I don't run into this issue.
I found the answer: Unity uses an extension to configure what they call "selector policies". To replace the attributes used by Unity, you just code your own version of the UnityDefaultStrategiesExtension class and register you own "selector policies" that use your own attributes.
See this post on the Unity codeplex site for details on how to do that.
I'm not sure that it's going to be easy to do the same if I switch to another IoC library but that solves my problem for now.
Couldn´t you just setup your configuration without the attributes, in xml. That makes it a bit more "unclear" I know, personally I use a combination of xml and attributes, but at least it "solves" your dependency on unity thing.
What are your best examples of using Reflection in production code?
ASP.NET MVC inferring the action and controller to invoke from URL. Routing in general.
Most recently, I had to use reflection to load an assembly (in order to investigate its public types) from just the path of the assembly.
Before Linq To Sql came out...I had to write my own ORM in .NET 2.0.
I used reflection heavily to reflect back on:
Classes to their CRUD stored procedures
Properties to their column names
Which operations were valid for the class
I also used reflection to handle all variable assignment after the results were retreived (all classes inherited an ActiveRecord class that handled the calls into the DAL).
Rough stuff...but after some performance tuning it wasn't half bad.
Pulling data out of an SQL table where you had an ID, a type, and other data
Then you could load "Chevrolet" and work with all of it's methods
I did have occasion to write a Python O/R mapper on one at one point, but it was a proof of concept and never went into production.
I do quite a lot of work that makes extensive use of the system data dictionary on a DBMS (for example a generic slowly-changing dimension loader). It might be argued that this is not dissimilar to reflective programming in principle.
Finally, Python in all its forms is very easy to do reflection with. In fact, it's so good at this that I've used it to poke about with underlying API's in other languages - and use the reflective capabilities to query the underlying interfaces. I have done this with pretty much every reflective mechanism that exists in the Python world: CPython on Python API's and COM API's using makepy, Jython for java API's and IronPython for .Net API's.
In one of my recent apps, an add-in for Kofax Express, I have an option to OCR a file and output a PDF. Since the OCR tool I'm using has a runtime fee, I made the OCR part a seperate assembly. If the file exists, I show the OCR options and late bind the assembly and invoke the required methods and attach to the events with reflection. A simple plug in architecture without interfaces, and saves customers from having to pay royalty fees if they don't need to OCR; we just don't give them the OCR dll.
WPF Databinding:
1) Binding path "(TextBox.Text)" vs "Text"?
If you bind to a path called Text, WPF uses reflection to resolve the name. If you use the class-qualified name, binding avoids the reflection performance hit. Class-qualified names also allows binding to attached properties!
(via http://dotnet.org.za/rudi/archive/2008/03/25/10-things-i-didn-t-know-about-wpf-data-binding.aspx)
NUnit Unit Testing Framework - Not very typical though
CSLA uses reflection a lot
Pretty much any Windows Forms app that supports plugins
My DAL is all reflection based. It reflects on the POCO properties to build SQL.
Within a factory, we use reflection to either pass back a "Dummy" implementation of an interface or a real (hooked to the DB) implementation of an interface, based on the class specified in a properties file (in Java).