Tuesday, November 3, 2009

Easing into Prism

I received a familiar email today:

Is it possible to start slowly with this Prism stuff and work my way into it gradually. Can I get something running quickly with DevForce as I know it now? My client has seen a prototype and I need to construct it soon. Then can I come back later and modularize the whole thing behind the scenes?

Here’s my reply:

You do not need Prism to get started!  You can introduce it into your application as you see opportunities that make sense to you. Prism is not a monolithic framework. It is a small collection of free-standing components that also work well together. You can adopt it a piece at a time; some of it you may comfortably ignore.

It’s definitely worth reading about. It’s worth looking at the Reference Implementation and the Quick Starts. Get the Composite Application Guidance book from Patterns and Practices, look at what folks are doing with it and saying about it.

Don’t get hung up on Prism itself. It is guidance first and implementation second. Poke around. See how other people tackle some of the same concerns. You might look at Caliburn, for example.

In other words, take your time and educate yourself.  You don’t have to dive into the deep end.

However, I feel strongly that you should start wrapping your head around Dependency Injection (DI) and Inversion of Control (IoC) containers as soon as you can.  They will completely transform the way you write your application. They will position you for future modularity and make your code ever so much easier to maintain.

Learning IoC is also a great career move.

When you see yourself writing “new XXX(…)” you will learn to stop and ask yourself, “Do I really want to lock myself into the XXX type or would I be better off if XXX were delivered to me instead?”  In recent years my answer has increasingly been to avoid “new” and let the IoC construct and inject the instance I need.

Don’t get carried away now. It’s a shiny new toy. Take it easy. But get used to it.

I know you asked about Prism and here I am waxing on about IoC. I only go on about this because your decision to use or not use DI/IoC is fundamental. Prism (and its ilk) will come along naturally if you use DI; they won’t seem so natural if your application is not DI-ready.

I promise the effort of learning DI (and it does takes some effort) will pay off quickly … and for the rest of your career. The principles are fundamental to emerging Microsoft technologies (see the Managed Extensibility Framework – MEF). Dependency Injection is the primary vehicle for implementation of most modern application development patterns.

You have plenty of IoC containers to consider. Microsoft Unity is one choice but by no means the only one: AutoFaq, Castle Windsor, Ninject, and StructureMap are popular (apologies to any I omitted).

Do not be overwhelmed! These alternatives are vying for your affections with tons of features and you may easily become convinced that DI is super-complicated.

You can ease into DI. Take a look at our “Prism Explorer” (which uses Unity); you’ll hardly notice IoC but it’s there. I limited myself to the simplest Unity techniques. If I remember correctly, I only use constructor injection, I register very few interface types, and I don’t use any of the attribute markup. You can go amazingly far without any advanced IoC features.

In sum, get going on your application and do not let these technologies distract you. They are important and valuable but you don’t want to destroy your business relationship by drowning in technologies that you know nothing about.

Get acquainted with Dependency Injection first and start using it experimentally. Learn about Prism in all that spare time.

Try partnering with someone who has been down this road before. If that is not possible, find a local users group and latch on to other like-minded developers. It’s much more fun when you play with others.


Ben Hayat said...

Great article my friend. Can you explain to me where Prism and MEF overlap and where they compliment? Although Prism is a Guidance and MEF is a framework. Is it one V.S. the other or what?


Jeff Doolittle said...

shoulda called this "easing into IoC"! ;)

I hope your readers will latch on to your advice to work on their grasp of DI and IoC. Learning this approach to development is critical, especially in statically typed languages.

On a side note, I've moved away from Unity and have adopted StructureMap due to its powerful "convention over configuration" approach to auto-wiring your dependencies. I am amazed at the speed with which I can develop when following some simple conventions and letting the container do the rest.



Anonymous said...

It was extremely interesting for me to read the post. Thanx for it. I like such themes and anything that is connected to this matter. I would like to read a bit more on that blog soon.

Anonymous said...

[b]buy enterprise software, [url=http://firgonbares.net/]coreldraw crackz[/url]
[url=http://firgonbares.net/][/url] cheap graphic software Pro Finale 2009 FileMaker
cheapest place to buy software [url=http://firgonbares.net/]serialsurfer quarkxpress[/url] downloadable antivirus software
[url=http://firgonbares.net/]commerce store offers software products from[/url] install oem software on
[url=http://firgonbares.net/]good educational software[/url] shop no fail software
downloadable software applications [url=http://firgonbares.net/]software store script[/b]

Anonymous said...

Interesting post as for me. It would be great to read more about that theme.
By the way check the design I've made myself Companionship in London

Edwin said...

Good read, what are the plans with the IdeaBlade framework to remove dependency on Entity Framework and allow development to modularise the business layer? Thus model different permutations of a business object for different implementations. The typical Product vs Solution scenario.

Anonymous said...

nice post. thanks.