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 mostly been a Database developer but to enhance my personal skills and to develop a windows application I am trying to learn the new things in .NET. A few years back I devloped a POS in C# 2.0. The only thing that I recall using in terms of a pattern or existing code library was the Data Library provided by Microsoft.
I am trying now to write a rule-based engine that has a good UI for the business user and performs very well, when processing the rules. One of the things I have decided to use is WPF.
The choice comes from reading at multiple places that it is the next step, and it seems to give a lot of options in creating Visio like diagarms.
Where I confused at is with these other technologies, design patterns and best practices:
MVVM
EF
WCF
WF
and there are a few more.
I am trying to look for a article or something that explains how these things work together and what is the best combination to use and why?
Thanks,
Without a lot of information to work with, I'd suggest you check out a few Microsoft patterns & practices (p&p) guidance releases that could help you design your solution well and also follow Microsoft's best practices.
The titles I'd recommend include:
Microsoft Application Architecture Guide (2nd Edition)
-- This will help you with the basic architecture and design of your application. The sections on service development (chapter 9) and workflow (chapter 14) should at least provide you with the basics to start with, and also provide you with some next steps on further research or additional information. There's also some mention of data access technologies, and briefly touches on EF, but you may be better off just consulting the data developer center on MSDN for specifics about EF.
Developer's Guide to Microsoft Prism (Nov 2010)
-- This will help you out with architecting your WPF app so that it's loosely coupled, and also provides information and guidance on MVVM (chapters 5 and 6)
I think these two resources will give you a good start on how to best use the various frameworks and technologies together.
Hopefully this gives you a good start. Let me know if there are more questions and I'll update my answer accordingly.
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?
Currently as my job profile i am more working on asp .net application but i also wanted to have my hands on silverlight application. so, i just decided to build one silverlight 4 application in my spare time and on weekends.
We are having a team of around 4 people. We also tried for commercial application but as we can only develop it in our available time we can not commit on timeline as well as we people are new to SL, so first we need to learn concept and implement it. (Though we know the concept of binding, commanding,templates etc.)
Now i just thought to work on project like creating a social networking site in SL 4
having facilities like forum, blogs, calander, task, dashboard etc.
We want to use features like .Net RIA Service, Entity Framework, MVVM pattern, SL 4.
Objective here is to learn new concepts as well as to get some good project experince in silverlight.
Now,
what you people suggest is it a good idea ?
If yes then the project selected is correct or you suggest some other project ?
Any pattern or technology related suggestions ?
This is quite a vague set of questions but I'll attempt to give my 2 pennies worth of advice.
As a learning project this is as good an idea as any to get going with. As a commercial idea it probably isn't such a good one due to there not being any niche in your product. It has all already been done, and been done successfully by the likes of Facebook and Twitter. Developing any kind of social media site is incredibly difficult as the market is already fairly saturated. As I said though, as a learning project it's quite nice as you can just borrow concepts and ideas from other sites and you can concentrate on you main goals of gaining knowledge in the various technologies.
Whatever you decide to do I'd say split the project up into much smaller components rather than having the end goal in sight. Try to take more of an agile approach by setting yourself 2-3 week targets. It should help keep the momentum going. My experience is that learning projects tend to die a death as people get bored of the concept and lose motivation to do it. By keeping the tasks small you get to see small results often. This should help keep you motivated as you move from requirement to requirement.
Personally I think setting up personal projects and goals like this are a great way of learning new technologies - good for you!! :-)
From a tooling perspective it sounds like SL4 is an ideal route to follow. This is highly likely to be released in early 2010 and has some awesome new features compared to SL3. Would also recommend using VS2010 and WCF RIA Service too.
From a code sharing POV have you considered hosting your project on Codeplex? This will give you a hosted TFS server to manage your source code in a distributed way. This is bound to save you some big bucks.
As far as document management is concerned Google Docs are certainly worth a look (as is Google Sites as a really easy to set up (albeit simple) project management portal).
Finally, I can't recommend learning SketchFlow highly enough. As a prototyping tool for silverlight it is really, really cool. Take a look at the PDC video for a great kick start on this.
Good luck :-)
I'm getting ready to develop my first Silverlight app. It is going to be primarily used by my church for data input but also will need to generate at least one report, ideally in Excel but XML/XSLT is not outside the realm...
It will be Internet facing and will talk to a SQL Server 2008 db for which I will be creating a web service hosted at the ISP (db is also hosted at the ISP). The clients will be a mix of Windows and Mac.
My question specifically relates to the interface architecture. I know MVVM is big for this right now and I'm comfortable with that. I want to get this up fairly quickly (ie- next 3-4 weeks). I've also seen mention of Prism (Composite Application Guidance) and Caliburn. What are anyone's thoughts on these two? The initial version of the app is not going to be huge so I don't imagine it would be overly difficult to refactor a framework into it at a later date.
You are right, if it's your first development on SL, adding the complexity of MVVM won't help you much.
I think a good approach could be to go for something simple (e.g.: the good old Document/View could be just a good start http://msdn.microsoft.com/en-us/library/4x1xy43a(VS.80).aspx, or just breaking in standard layers, UI / BS / DL).
After that development you will have learnt a lot of good stuff, and then you will be able to throw your app and start new bigger challenges using more advanced architectures (about MVVM, a very good web cast: http://blog.lab49.com/archives/2650 it's WPF based most of the concepts can be ported to SL).
Good luck and enjoy for SL development.
Cheers
Braulio
Start with something you are very comfortable with especially if you need to get this up quickly. Follow good coding standards and should not be a problem to refactor later into other frameworks if you get a bigger team.
This is a useful pdf.
I haven't read it in detail yet myself, but this article looks rather useful:
RIA Architecture with Silverlight in mind