I'd like to start using IoC Container in an existing WPF application.
I need good performance, but from what I read, performance is really not an issue with most containers.
What I need most is a very easy to use container, that can be easily integrated into my app. I read recommendations about StructureMap (and the syntax looks great), but in their site it seems that there were no updates in the last 3 years, so I'm having some doubts about it.
Please provide recommendations with basic usage code samples (initialization + usage).
Edit
I'm not looking for a complete framework. I only need the IoC container ability, so many other alternatives exist. The last relevant discussion I found here is a few years old and I'd like to refresh it.
The answer really depends on personal preference and the details of your use case. Anyway, after using Unity, MEF (I know, not a real IoC container) and writing some individual solutions, I am now using Autofac and like it a lot. It is very easy to dig into and continuously reveals its advantages the longer you use it. It provides a fluent interface and is fast, compared to other frameworks (btw: The performance of your container can be a very important issue, depending on what you want to do). For usage and samples of Autofac see the link above.
Why I like it:
Easy to get into
Fluent interface
Supports open generics
Supports assembly scanning
Interoperability with MEF and other frameworks
Fast enough (Performance comparison of IoC containers)
Still, this is personal choice and there are other good solutions around, which might even be better for your special case.
And, more or less off-topic, I can recommend this article, especially the second half, for general considerations. It helped me a lot. So, just in case:
Article by Martin Fowler
Structuremap aint dead.
We are using it for our new green field project, and when v3 is out we may migrate to it. ATM using 2.6.4.
Your question is a shopping-list type question so it won't stay open long.
There are a number of IoC type frameworks, some of which require declarative or programmatic manipulation to do their work, some of which use code semantics to wire things up.
I would suggest you start with Unity1 until you get into the swing of things, then look to branch out into some of the more exotic frameworks when you can appreciate the differences between them.
1 Here is a good recent intro article: Visual Studio magazine: Creating Modularity with WPF, Prism and Unity
Related
It's possible to find tutorials on MVVM and DI, somewhat harder about getting Data from database properly into GUI.
Finding something that talks about all these things and how they integrate is near impossible.
I guess some people will say that it doesn't matter and all stands independently but I don't believe it. Especially considering MVVM and Data as I find keeping a tight grip on data managing while doing MVVM to be the hardest part.
So is there anything I could use, and I don't wan't some small simple problem solved but something near complete, at least steps from DB to GUI dynamically done. I'm willing to pay for such a book.
You could look at Prism guidance provided by Microsoft Patterns & Practice group. Prism is actually complete architectural approach to build enterprise level solutions. But it contains StockTrader Reference Implementation application that is built using DI, MVVM and includes interaction with data storage (they use XML files as data storage to provide easy distribution, but it really doesn't matter what data storage is used). Also, the guidance contains several small quickstart projects which emphasize particular part of the architecture. There is comprehensive documentation and active community around Prism, so you can find answers to any question. And it is completely free.
Among many other things my book Dependency Injection in .NET discusses all of those things. However, the subjects is DI first and foremost, with MVVM and data access only incidentals. However, you may find some of the code examples accompanying the book helpful.
In addition to Prism guidance already mentioned, I highly recommend Karl Shifflett's MVVM In-the-Box tutorial. It has great content and also encourages you to experiment with code as you progress through the topics (it is integrated with Visual Studio).
You might be interested in the BookLibrary sample application of the WPF Application Framework (WAF). The BookLibrary shows how to use MVVM, DI with MEF and data management with Entity Framework and SQL Compact Edition.
I have done one full project using WPF, and have (at least) a pretty good grasp of the main concepts, like XAML, Databinding, and MVVM. We did everything "by hand"--we did not use an MVVM framework or third-party tools. All XAML was written by hand as well (no Blend).
The new project I will start in a few weeks is pretty heavy-duty Silverlight, and I'm looking to get up to speed as quickly as possible. However most of the articles I've read on getting started with SL focus on XAML and databinding. Since my introduction to these concepts is still very fresh in my memory, I can certainly understand why these tutorials would spend a lot of time on these subjects--the learning curve can be very steep. However these are concepts that I am already familiar with, and find myself having to wade through a lot of covered ground to learn anything new and compelling.
So what I'm looking for are advice on what I need to learn and understand to go from being a journeyman WPF'er to a journeyman Silverlight'er. This can be in the form of:
General Advice
Key Differences
Rules of Thumb
Resources/Links ("A WPFer's Guide to
Silverlight" would be perfect :)
Major Pitfalls/Things to Watch Out For
Thanks in advance for any insight.
Rob Eisenberg (creator of Caliburn and Caliburn Micro) has a series of blog posts that talks about porting a WPF application to Silverlight. This may give you some insight into some of the framework differences.
Day 1
http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/25/porting-nhprof-from-wpf-to-silverlight-day-1.aspx
Day 2 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/29/porting-nhprof-from-wpf-to-silverlight-day-2.aspx
Day 3 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/31/porting-nhprof-from-wpf-to-silverlight-day-3.aspx
Day 4 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/01/porting-nhprof-from-wpf-to-silverlight-day-4.aspx
Day 5 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-5.aspx
Day 6 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-6.aspx
Day 7 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-7.aspx
Day 8 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-8.aspx
Some other thoughts off the top of my head:
Binding defaults to One-Way
No DynamicResource
TabControl is fairly different
No ability to define implicit DataTemplates for types
No CoerceValue in Dependency Properties
Event routing is very basic
No built-in command structure. You have the ICommand interface, and ButtonBase controls have a Command property, though there's no class that implements the ICommand interface.
Missing x:Static, x:Type
All service calls need to be on a different thread than the UI thread. This essentially requires you to learn / implement async programming strategies. See here and here.
As was mentioned, it's a different framework so not all libraries are available to you. Example: there is no XmlDocument - you have to use XElement (which is arguably better, though even so)
The Navigation framework is totally different than WPF. Stay away from it. It will only cause you pain. ;]
Several of the Controls that you find in the core framework in WPF you'll find in the Silverlight Toolkit. Download it, you'll need it.
No built-in Triggers, though can use behaviors / actions provided in the Blend SDK (which essentially gives you the same thing)
If you need to interact with a database, it will have to be through services hosted somewhere, or through COM (which means Silverlight 4 OOB with Elevated Permissions).
I disagree with Kevin in that testing is actually fairly easy and all of the major testing frameworks and mocking frameworks support Silverlight. Where you run into issues is Code Coverage. The Microsoft Testing framework supports Code Coverage (Premium & above) or else you can use dotCover. I believe newer versions of nCover supports Silverlight though I'm not 100% certain. Use StatLight to run your Silverlight tests (regardless of testing framework) from the command line.
If you're not already using an IoC container pick one up. Autofac, Ninject, StructureMap, Unity, MEF. (Another bias of mine ;])
I would highly suggest looking into the available MVVM frameworks. This has cut down a significant portion of the framework code I typically have to write. The frameworks will probably only get you 80% of what you need, though that's 80% you didn't have to write yourself. I'm currently partial to Caliburn Micro, though most of the popular ones will give you what you need.
I'll add more if I think of more. Good luck in your journey!
I've really only done Silverlight for a real app...but one of my co-workers was a big WPF guy, and so I hear some of his gripes.
You're going to probably need to use a WCF service, etc., for asynchronous queries to your service/business layer
You're using a subset of the .NET framework, so you cannot include ANY of your class libraries as a reference, only Silverlight class libraries can be included. However, you can do stuff like having a 'link to existing file' in a silverlight library that links to a file in other libraries...as long as the code still compiles with only the reduced set. This is a bit of a maintenance nightmare, but if you are doing WPF & Silverlight with some of the same code, it will probably save you from a lot of replication. Make sure to make it a link to the file and not a copy of the file, or changes in one won't change the other.
Unit testing your ViewModels will not be as easy. Need to Moq your service and use a Silverlight unit testing project.
Some of the reduced functionality is annoying for WPF veterans.
I think our WPF guy complained about not being able to bind stuff like a CanExecute method as easily on his commands as he was able to do in WPF. He had to call the method directly from the command or something. (I've only gotten a chance to look at MVVM a little so far as I'm now on a different project :(, so not quite sure on that one).
Hope that helps a little.
I am using delphi as my primary development tool.
and recently I found these 2 libraries in KSDEV.com
and i found they are similar to WPF . So i just downloaded them and stated to playing with them until the time to end comes ( i have not checked its license policies yet). I am not a good WPF knowledge person but i found was WPF hard to develop.
But my doubt is , are these 2 libraries can replace WPF in delphi . what are the drawbacks Dxscene and VGscene have or what are the drawbacks WPF have ,
There are only a little articles about them in internet (google gave me millions of results but most of them repeated 2 articles which was published in KSDEV)
VGScene and DXScene can be compaired to WPF for the rendering result.
I think VG/DXScene are less resource consuming, and what I like against WPF, is that they are not XML-based.
You use regular Delphi components to define your UI.
But the learning curve and the documentation is still a bit lacking for VX/DXScene.
I found out to be a bit difficult to create forms with DXScene. VXScene is perhaps a bit easier to create your UI with the mouse.
I think the full power of these libraries will be obtained using code-generated UI.
I don't like the XML root of WPF. It's verbose, and difficult to work with, with real application with a lot of forms. For some projects, the external WPF designer could be necessary.
But don't ask Microsoft why they don't publish WPF-based applications... and they still use unmanaged code...
VgScene and DxScene are really cool libraries! You can make fast and nice looking GUI's with all kind of effects. It also has a grid component now!
But when I tried using them, I encountered some "drawbacks": there is little documentation how to make and what to use for a complex GUI (there are some nice demo's for simple GUI's though). So it has a relative high learning curve (when you only have VCL knowlegde because it is very different).
But besides these things, I think it is worth trying (only if you know how to do it and/or spend some time learning). It has good platform support (via FPC and OpenGL) so you can run it also on MacOs, Linux and iPhone/iPad!
Since they do not depend on WPF, they can be used for cross platform development in Lazarus/CodeTyphon. That is the main advantage for me. Drawback is documentation.
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 12 years ago.
This is a question I have had rattling around in my head for some time. I had a chat with a guy the other night who told me he would not be using the navigational framework because he could not figure out how it works with MVVM. As much as I tried to explain that patterns should be taken with a pinch of salt he would not listen.
My point is this, patterns are great when they solve some problem. Sometimes only part of the pattern solves a particular problem while the other parts of it cause different problems. The goal of any developer is to build a solid application using a combination of patterns know how and foresight.
I feel MVVM is becoming the one pattern to rule them all. As it is not directly supported by .Net some fancy business is needed to make it work. I feel that people are missing the point of the pattern, which is loosely coupled, testable code and instead jumping through hoops and missing out on great experiences trying to follow MVVM to the letter.
MVVM is great but I wish it came with a warning or disclaimer for newbies as my fear is people will shy away from silverlight development for fear of being smacked with the mvvm stick.
EDIT:
Can I just add as an edit, I use and agree with MVVM as a pattern I know when it is and isn't feasible in my projects. My issue is with the encompassing nature it is taking, as if it HAS to be used as part of development. It is being used as an integral feature and not a pattern, which it is.
EDIT 2: Thanks for all the comments so far, one issue that is surfacing from this is something I have not thought about until now. Is the introduction of richer more advanced frameworks for GUI/RIA development showing a weakness in RAD development for this generation. That is, is there a lack of code design and pattern knowledge being taught along with these frameworks? I once asked for a book on just C# (Before Pro C# & the .Net framework was popular) and was told why would I want to know C# minus winforms/asp.
Sure there are plenty of books/KB on these subjects but are people using them, beyond the superstars and very good programmers?
So, here's something that I think a lot of new MVVM developers forget - the pattern is there to help you, not the other way around. Building software in this manner tends to make your life easier as your project gets larger, but if it's completely getting in your way for a specific task, take a step back and ask, "In this specific scenario, is MVVM helping me here?" You're allowed to "cheat" a bit from time to time if it makes your life easier.
Actually I've used MVVM quite effectively with Navigation Applications with the Windows Phone 7 framework using commands and messaging. But if someone tells you that you can use every feature of Silverlight without adding some code to the code-behind, then they are fooling themselves. Use the pattern where it helps and make sense, and go "off-pattern" when a particular feature requires something custom.
Assuming your question applies to WPF as well, I sort of wonder if the problem isn't just the massive learning curve of WPF/Silverlight, before it even occurs to you to try out MVVM. Think about all the new things that need to be learned with WPF (and I assume Silverlight): XAML, dependency properties, attached properties, routed events, routed commands, static resources, dynamic resources, styles, data templates, control templates, databinding, etc., etc. etc. Then take the fact that Microsoft released this technology with an incomplete set of, at least with WPF, badly skinned controls, and you have a recipe for frustration and the inescapable feeling that you are dealing with a technology that is "not ready for prime time". I mean, before the WPF Toolkit came out, there wasn't even a proper DataGrid control.
Once you understand all these things, MVVM is yet another hurdle, but I don't think it's the main impediment to people jumping on the WPF/Silverlight bandwagon. That said, it would be nice if Microsoft would get behind it the way it has gotten behind ASP.NET MVC. As it stands today, you have to download and use third-party tools, like MVVM Foundation and MVVM Toolkit (which, incidentally, have a lot of overlap and should be combined into a single project).
So, I agree with you to a point, but I think most of the challenges involved with MVVM are probably due to the lack of support from Microsoft, and the inherent complexity of WPF/Silverlight, not due to any flaw in the MVVM pattern itself.
Great answers here, by the way. Good discussion and an important one to have. There is no doubt that learning Silverlight can be intimidating for new developers, and the MVVM framework will no doubt compound that.
However, I do agree that someone not understanding it isn't a dig against the framework. I still have developers who tell me that inversion of control/dependency injection is too confusing to learn, but does that make these invalid patterns? The fact the so much proven, "in the field" software relies on those concepts tells me they are sound even if complicated to grasp at first or understand.
Then again, learning a foreign was tough when I started, but once I pushed through, now I can speak it comfortable and wonder why it was so hard to begin with.
I guess the trend that scares me the most is this notion that for some reason complicated, enterprise applications should be easily built by beginner developers who either can't or won't grasp complex concepts. That's what it really boils down to. You don't have doctors saying, "Help, make this brain surgery easier so any one can do it." It's specialized. Building great software is also specialized, that's why consultants command good payment for their services: it's the value they provide in understanding the right way to architect and develop solutions.
If you are making an asteroids game, a fantasy game, a media site, a YouTube knock-off, etc, then you probably don't need MVVM and it is overkill. If you are building a small site with a few forms and graphs then build it how you are comfortable and be done with it.
If you are building a large, complex site that is composed of multiple, dynamic modules, moves thousands or millions of records and requires scaling to massive concurrent users, then you can't expect the design to just pop out after thumbing a few pages of a book or skimming a few sites. Software like that is complicated, with a lot of moving parts, and rqeuires a firm grasp of architecture.
What amazes me is people presumably building these more complex applications who still don't get building these more complex applications. Is there someone experienced on the team? Do you have an architect to stub out the framework that you can consume?
I mean really, the example just tells me the problem isn't MVVM, it's the developer. "Avoiding Navigation because of MVVM?" REALLY? What's MVVM got to do with it? Write the navigation pieces, and let the view models live inside the pages. Why does my navigation have to drive from a view model?
Come one. If it's that complicated I think it has nothing to do with the pattern, and everything to do with the developer just not understanding development. Don't blame the pattern. Maybe they need to stick to simpler applications. In my experience, people who come to understand the pattern understand software well enough that they know when and when not to use the pattern.
I know there are many movements to boil it down and make it simple for the "average consumer" but I think this is like trying to say, "Calculus is the wrong way to find the area under a curve because it's too tough to learn." While MVVM isn't as complex as Calculus, building complex software is a complex endeavor and I don't think you are ever going to simplify it or boil it down to a simple formula (nor should you). If you struggle with MVVM, please, don't use it - find something simpler and easier. If your project is complex enough to use it and you still don't grasp it, please hire someone who does, have them plumb it out and learn from them.
No, I don't want Microsoft telling me what pattern to use nor do I feel it is their responsibility. I'm a professional and it's on my shoulders to invest the time to learn and understand what I'm building so I can build it the best way for the customer. Microsoft doesn't necessarily know what my customer does or needs, so how can they possibly tell me what pattern to use? Projects like Prism are great because they are a compromise: they provide guidance and share "best practices" of how something can be done, without forcing that implementation on the developer.
I'm using MVVM for a Windows Phone 7 app. I really like the idea of it but there's too many hacks, wordarounds and 3rd party tools needed to get it running.
Things are getting better with every release of Silverlight but I still think the technology is "bleeding edge".
Why can't you?
And no, MVVM is just one of many patterns and frankly, not even amongst the most popular ones. What is hurting Silverlight's development is a) Flash b) not being Flash c) being Microsoft centric d) learning curve.
Plus the fact WPF doesn't really seem to have caught on doesn't much help.
Someone has problems figuring out how to use navigational framework with MVVM => Someone doesn't use navigational framework => MVVM is killing navigational framework => MVVM is killing Silverlight development.
Would you say there are few flaws with this chain of reasoning?
I'm trying to build a line of business application using Silverlight. I felt like I was doing good then someone asked some questions. Immediately, I became really confused. I see discussions around Prism, Unity, and the Managed Extensibility Framework. However, they all look like they are trying to solve the same problem. Am I nuts? How do these three items compare / contrast with one another?
Thank you!
I recommend listening to the Herding Code podcasts with Glenn Block. (Part 1 and Part 2). He goes into this exactly subject, in much more detail than we can answer here.
That being said -
MEF and Unity are the two things that have quite a bit of overlap. Prism, in its default form, uses Unity for its dependency injection. You can use Prism with MEF, if you like, instead.
Prism is designed more for building composite applications. MEF, on the other hand, is about extensibility. There is definitely some overlap in goals here, but the basic driving factor is different.
In Prism's case, it's all about organizing known code.
MEF, on the other hand, is about discovering new code, and injecting it appropriately.
The newest guidance I've seen, which I fully agree with, was just posted on Glenn Block's blog: "If you are starting fresh you can use MEF for modularity, and general aspects of your composite app. Where appropriate you can pull in Prism bits."
http://blogs.msdn.com/gblock/archive/2009/12/02/mef-and-prism-to-be-or-not-to-be.aspx
There was this post today that discusses two scenarios where MEF and Prism work together to provide solutions. Each scenario leverages features that are not found in each, with 80/20 rules for those features that they do share.
Although there is overlap, the essential differences from a 30,000 view are
Unity is a IOC container. Use it to make your app more loosely coupled
Prism is gear toward making your UI more loosely coupled. As Reed mentioned, it uses Unity to help do this.
MEF is meant to make your code extensible. This helpful when having to interoperate with code that will be written by someone else. An example is if your application will support plugins.