All,
As far as I understand ASP.NET MVC is the framework that implements the MVC pattern released my Microsoft. I wonder why there is no Winforms or WPF MVC implementation ?
The reason I am asking is that I am planning to start on a new big WinForms project and ideally we are looking for a framework that implements some kind of common pattern to improve the testability of our solution.
Thanks,
MK
For WPF, the MVVM pattern is so deeply ingrained in the framework itself that you don't really see it until someone points it out to you. You don't really need a separate framework for that (although certain types, such as Josh Smith's RelayCommand, would be nice to have in the BCL).
Windows Forms isn't really going anywhere anymore, which is why you don't see any new or thriving MVC-style frameworks for that platform. However, patterns & practices' Composite Application Block (CAB) was an attempt at such a framework.
Most people found the CAB to be too complicated to their taste, but I personally found it a valuable effort, even if it could have been simpler to use. It's still out there and available in source code format, so you might want to take a look at it.
However, if at all possible, implement your application as a WPF application instead.
If you want to use WPF you should look into using the MVVM pattern (Model View View-Model).
There's a template you can download for Visual Studio for it. It's part of the WPF Toolkit I think. Look on CodePlex.com.
Hope this helps!
There are a few similar SO Questions here and here.
Just because there is not a strict framework for MVC in webforms/wpf doesn't mean you can't follow the principles and code in an MVC way. I think MVVM for WPF is similar although I have no experience of this.
As Tony said, read up on the Model-View-ViewModel pattern (essentially, this a variation of MVC, but better suited for the WPF programming model
Have a look at the Composite Application Library for WPF and Silverlight (from Microsoft P&P). I can say from experience that this library is a lot easier to use than the Composite Application Block...
The Caliburn Framework is also worth looking at
WinForms are dead. You better look at WPF+MVVM (+Prism)
What an excellent question asked here: Why isn't there an MVC equivalent framework for WPF? I spent 6 years on WPF platform only to find out:
No further development on the WPF toolkit ever occurred since fist release.
Hosting web browsers in WPF still has major air-space issues.
Charting was never fully ported to WPF.
VS2013 never was provided with an WPF MVVM template for new projects.
Prism is confusing.
Learning curve is steep.
The open community hardly developed any open libs. like Javascript folks did.
Running it as an in-browser app. was very difficult to get right.
Compared to Web-Client rendering it is just plain slow.
And perhaps worst of all Microsoft went quiet on us. Until just recently announcing they're back in the game, but if you look at their plans it looks more like a Sunset release than getting back in the game.
The solution for me is to dump WPF in favor of MVC which I've done. MVC has its quirks but it's a much nicer platform than the cantankerous framework that's best suited using the "Relay Command" what a pile of nonsense.
Imagine your boss saying, hey we need that in a web browser and your reply "It'll be ready tomorrow"...
Related
I'm looking into getting started with C# app development. I have experience in web-based technologies but am just starting up with desktop/MVVM.
I've been watching and reading up on various mvvmcross tutorials, and I'm really looking forward to working on an application using the framework, but I just have a quick question which might have more to do with databindings than mvvmcross itself:
If I build my application.core through the mvvmcross library, would it be relatively easy to reuse that core library to develop UI's for non-mvvmcross targets?
I understand that mvvmcross simplifies a LOT of the display logic, so by doing this I would have to write up code to connect with other guis using their methods, but I'm wondering if anybody can comment on
a) Whether it would be possible
and
b) If it would be possible without a lot of workarounds/hacking around my mvvmcross core implementation.
My use-case is that I plan on using mvvmcross to develop for either WPF or WinStore first, then, if there is demand, add a Mac UI. But eventually, if the demand is there, I want to be able to also port my application to Linux (probably through gtksharp,because it sounds like that's furthest ahead in development right now). Would my application.gtk project be able to easily call/work with the classes, methods, and functions that are defined in the mvvmcross core application, or would that logic have to be re-written to handle data in a way that's more suitable to gtksharp?
Thanks.
Sorry for the super-late reply, but I don't really think this is too feasible, at least as stated. The main problem, as I see it, is that MvvmCross would still likely have to be a dependency for most of your core library(ies). You could certainly have a core library with that as a dependency and just not really use it, but that seems like a waste and kind of goes against the question as asked.
Without it as a dependency, you lose quite a lot of stuff, really all the stuff that makes it such a nice framework. What you'd really want to do is just implement INotifyPropertyChanged and work off of that. Some other, simpler libraries you might be able to use include the Bind library from Praeclarum (https://github.com/praeclarum/Bind), Fody.PropertyChanged (https://github.com/Fody/PropertyChanged), Json.NET, and SqLite.NET to achieve a basic but powerful core library that can then be added to with an MvvmCross-based library, but I don't know if there'd even be any reason to do that. Another helpful link would be: http://arteksoftware.com/end-to-end-mvvm-with-xamarin/.
Normally when developing the core with MvvmCross (but actually any Mvvm pattern using style of development) the Core should not depend on any UI logic, and thus should be re-usable on any platform. However currently there is no platform support for gtk in MvvmCross.
I'm not really familiar with gtk, but I suppose it's possible to build the binding layer for linux in a similar way as was done for Android and iOS.
So in theory you should be able to re-use the Core libraries on Linux as well using Mono, given such binding layer for Linux would be developed for MvvmCross. I'd be interested to see anyone start poking around if this is actually possible.
Can you please tell me some tutorials/books about thinking a large application in c#.
I have worked with 3 tier, but i need something more specific:
a way to design panels, so that for specific users specific panels will load and specific dlls
a database management so that when a user modifies an entry, others can not modify that entry
should i use entity framework or should i go old school with db and class creation
any links on the above will be greatly appreciated
thanks a lot!
Kind of a broad subject but two books I would recommend giving a read regardless of what language you are doing or the specifics of your project:
Code Complete
Design Patterns
If you have specific questions about how to accomplish something I would post it on here or google it.
Sharp Architecture is just such an architecture. It's pretty detailed and a lot of work has gone into it.
NDepend documentation comes with two white books and also online blog posts and articles concerning the architecture for large .NET application:
Partitioning code base through .NET assemblies and Visual Studio projects (8 pages)
Defining .NET Components with Namespaces (7 pages)
Control Components Dependencies to gain Clean Architecture
Re-factoring, Re-Structuring and the cost of Levelizing
Evolutionary Design and Acyclic componentization
Layering, the Level metric and the Discourse of Method
Fighting Fabricated Complexity
That's not gonna be covered by a single book or tutorial.
You need to decide a UI framework, data access technology, patterns and the overall architecture. And of course you need an in-depth knowledge on .NET framework, & how the CLR works. It's nothing C# specific. Since you have UI customization (Panels) requirements, WPF is definitely a better candidate for UI framework, than WinForms.
That being said, my recommendations -
For C#: Pro C# 2010 and the .NET 4 Platform
.NET & CLR: CLR via C#
UI Framework - WPF: Pro WPF in C# 2010
Use MVVM with WPF. MVVM will keep you on track maintaining the Separation of Concern. You can follow Microsoft's Prism guideline. For large applications with sophisticated UI requirements Prism is a better choice. You might need to use Dependency Injection. MEF is there to go hand-to-hand with MVVM & Prism.
Yes, Entity Framework can handle concurrency issues, but such feature is available in almost any other data access framework. Entity Framework provides lots of other facilities, but when using it you should have clear idea of what you're doing. Otherwise you might end up with performance issues. Programming Entity Framework is definitely gonna help.
With respect to the panels/UI architecture, it might be useful to look at Prism (from Microsoft patterns & practices). It's an architecture/set of libraries to handle composite UI, where the UI is loaded at runtime and composed of independent communicating parts. One note, it is built for use with WPF or Silverlight; there is an older library with similar functionality for WinForms, called "CAB", that is no longer supported.
As far as data access, it sounds like you are looking to implement active record locking while a record is open for editing in the UI; this is an independent feature from the actual data access code you use. It might be easier to implement database-level locking if you are using straight ADO.NET versus EF, which adds layers of abstraction.
Microsoft .NET: Architecting Applications for the Enterprise - with a very good code example and there is a chapter on concurrency
Professional Enterprise .NET
ASP.NET 3.5 Website Programming: Problem - Design - Solution
I guess, there are not any online recources that could compete the complexity of these books.
My go to book with these kinds of questions is Jeffrey Richter's CLR via C# book. It takes you all the way from how your class construction impacts memory on the stack/heap to best practices for these types of discussions. Especially loading assemblies on the fly and the best way to accomplish this.
It will also bring your skills up a notch and Jeff is a great writer.
I recommend this book to EVERY C# developer I know and they always come away better. Is that what we all hope for?
Good luck!
If you want to learn fast and get to the meat of the technology fast, I would recommend getting a Pluralsight account as that would cover the technologies you would need and highlight others you may not have heard about. A monthly subscription would be about the same cost as a decent book.
Pluralsight.com
I'm about to start developing a small Windows application using Microsoft Visual C# 2008 (Express edition). I'm very new to C# and .NET, so this is a newbie question. Should I start with WPF or should I stick with the old WinForms?
My application has several screens, all having several text-boxes, check-boxes, combo-boxes, not anything more. The application will retrieve data from several COM objects, and communicate through standard TCP/IP sockets, both of which are unrelated to the UI.
The UI is not fancy in any way (and I don't need it to be). However, the world seems to be moving to WPF. What are the considerations of choosing WPF over WinForms for my case? What's the recommended approach?
Thanks
I have not used Forms enough to say anything about which is better, but I have found WPF to be easy enough to use for minor applications.
I figure that if it's the standard people are moving towards and it's not difficult, then it's good practice to start using it.
WPF = Future + Fancy stuff
WinForms = WYSIWYG greatness
Choose whichever of the above you find the most atractive :)
It depends. Stick with WinForms if you're comfortable with it.
If you want to be able to have a better look-and-feel with more customized controls, and you're willing to spend the time to learn XAML and the differences between WPF and WinForms, then go for it. But expect it to take some time, there is a learning curve.
Interesting, how all answers target the developer: familiarity with a framework, the learning curve, the technical features of a framework etc.
If it's a simple application, none of the technical aspects really matter. You sound like you have some experience programming, in that case the chosen framework doesnt really matter. Focus on your users instead.
Can you guarantee that your users have the latest .net runtime installed? Are they willing/able to install it if they dont?
Will your users be put off by an "outdated" look and feel?
The way you phrased your question, i think you should use WinForms. You seem to imply ("stick with winforms") that you have experience in WinForms and that you dont have any fancy demands for the UI, so i see no reason to put yourself on a steep learning curve that WPF can be.
I personally like alot of the things that WPF provides. It has easy data binding, validation, and customizing UI things is simple. Plus with the new Expression Blend 3.0 that was released yesterday they have sketchflow WPF apps that you can share with others and get feedback files from. It is a pretty interesting little addition to the WPF world.
The nice thing is that if you find a Winform control or something that needs to be WPF and you picked the other way, they seem to work well with each other now.
It's a trade-off.
You will most likely be more productive starting off in Windows Forms because the programming paradigm is closer to most other UI development libraries you might be familiar with. There are also many libraries of UI control available for WinForms (including ActiveX) that make creation of attractive, functional UI easier. Unfortunately, MS has indicated that WinForms will not see any more advancement in the future because their emphasis is on WPF.
WPF, on the other hand, is more more sophisticated and robust and can help you create very attractive, rich interfaces. WPF sometimes requires the use of more sophisticated back-end programming paradigms like MVVM to create effective applications. Also, as a newer technology, there are fewer mature libraries and tools to help you develop WPF apps. For development tools you have VS2008 and Expression Blend (which is quite nice BTW). Advanced graphics features like gradients, color themes, skinning, control customization are all more powerful in WPF. But this power comes at a price - most developers find WPF to have a more significant learning curve that WinForms.
WPF is something completely new if you are used to WinForms, so it'll take quite a while to get used to it. But i prefer WPF not because of the looks, for me it's more the great layout system (once you got used to it), its databinding infrastructure and in combination with patterns like MVVM, the separation of UI and business logic.
I have to develop a basic "line of business" application with the usual functionality like orders, stock control, sales, reports, etc.
I will use WPF to develop this application to run on Windows but I want to develop it "open" so I can do a Windows Forms application using the same structure (maybe to run over Mono) or even a Silverlight module. Can someone that did something like that (and survived) give me a sugestion on a guideline or something like that where I can find good practices? I'm a Delphi developer with some intermediate knowledge on C# but there are so many "amazing" libraries, frameworks and patterns that I'm a little lost on what would be good for that project.
Something like: Use EF (maybe wait for ef4?) or nHibernate, or ADO.NET, and expose your data using WCF, or webservices, or forget Mono because of the flexibility loss, etc. Can someone give me a tip on how you would do it? If someone has a bad experience in this type of project, it would be nice to hear from you as well. There is a lot of learning in the wrong decisions too :)
Mono doesn't implement WPF, it's not even on the roadmap. I'm not sure about Entity Framework...
You could probably do it in Silverlight (which has an open source implementation), but it's not ideal for creating desktop (although it is possible since Silverlight 3)
Where do I start?
First, from your description, you're in over your head.
Second, you're trying to pick a technology stack when everything is new to you.
In the best situation, I'd recommend a good training class in a few of the technologies you mentioned so you get a better understanding of them. I'd also recommend a mentor, someone who's done this before.
Reality though, may not allow for training or a mentor. In that case I'd recommend writing several real-life throw away programs. Take one piece of business functionality and try to write it in a few of the technologies you mentioned. If one feels better, and gives you what you want DECISION MADE! Don't stop with the first one that seems to work, try some more.
You should also listen to some good podcasts. I recommend Dot Net Rocks for a good grasp of the technology. The earlier podcasts for this site were also a very good source for some design discussions StackOverflow podcast
Best of luck.
I had to do something very similar recently in WPF. I have an ASP.NET background, but I have never worked with WPF (or WinForms for that matter), and it had me stumped for a while, but the longer I have been working on it (about 3 weeks now), the easier it has gotten. I really just searched Stack Overflow and Google for code snippets similar to what I was doing, and worked through them and changed them as needed. My company bought a book that helped me out as well (It was WPF Unleashed published by Sams), and it was pretty good. I do wish you luck on your first WPF app.
If you separate the business model and business logic from the user interface,
using MVC (Model View Controller) or MVVM (Model View View-Model) or a simular design pattern,
then you can have multiple user interfaces connected to the same business model + business logic and even connect the same user interface to other business models + business logic.
Thank you all for your suport... Brad, I'm already following your advices, doing some test cases to see what looks good... my problem is that altough I can develop an application in WPF and have a intermediate understanding in using the wpf databindings, generics, linq, anonymous objects, all the cool stuff, I always hear about this and that as the solution for all the worlds problems (like mvvm, or parallel programming, or functional languages, etc) and makes me feel "wrong" in my decisions and a bad developer if I do not use any of this nice technologies. I know the concepts but do not dominate it, and seems a lot of things to learn, sadly I do not have that much time.
Thomas, exactly because mono do not support WPF i want to make the application as isolated as i can, so I can do a simple winform layer to manipulate the data.
darthnosaj, thank you, I'm doing that too, searching internet and found much information (and this nice site full of hellpful people :) )
And Danny, thats what i think i need... will take a look on some sample applications using mvvm and see if that works for me. For what i heard is almost a crime not to use in that case in wich I want that kind of isolation.
Again, thanks all :)
I would suggest you keep your application N-Tier. Make all the entities, data adapter, and business logic separated from the actual desktop application. This way you can use WPF on the Windows platform and use Mono/GTK# on the Linux/Mac platforms.
You will only need to write duplicate code to support the actual GUI application functionality, while your code from the separate entity/data access/business logic library (e.g. DLL/class library) can be used in both your WPF and Mono/GTK# projects. Just add the DLL as a reference to the WPF and Mono/GTK# projects.
There is a good video from Channel 9 on building N-Tier applications
There is also MSDN documentation and guidelines on building N-Tier applications
So I've been thinking of going for Microsoft certification and I have to make a choice (for now) between Windows Forms and WPF for developing Windows applications. I have had good exposure to Windows Forms but never tried WPF before. Furthermore, most of the job postings where I live seem to be WinForms-oriented. That might change in the next few years, so I was wondering if I should get started on learning WPF or stick to the tried and true Forms.
Any insight?
Although most current dev.positions will focus on WinForms (or ASP.NET for that matter), WPF is starting to get accepted as a 'serious' platform. With serious I mean that
people are starting to think about using it for LOB-applications. With the release of Prism it's clear that Microsoft is starting to promote WPF in other ways than just the
'eye-candy' features. This means WPF is going to be presented as a WinForms alternative pretty soon.
Learning WPF will mean you'll also learn Silverlight at the same time. So you have two modern technologies at your disposal.
[Added] -WPF has more to offer than just the eye-candy and you can benefit from it a lot without being a creative genius. The API is intuitive (and fun) and can offer a lot of improved productivity.
In short, I'd say if you want to be 'future-proof' learn WPF.
In "enterprise" programming, I don't see an immediate need for WPF development. The reasons for this:
Companies are not running on the newest hardware, and tend to migrate to remote desktops (RDP/Citrix).
A developer can design a decent interface using Windows.Forms controls. In WPF, you need a designer. In large companies there are designers, in most companies I know, the IT department is staffed with programmers and system-engineers, no designers.
Software for the "home market" is another story.
If you want to go the certification route to learn then WPF is a good choice. It will take a few years before it will really take over from winforms but It's a safe bet it will so it's a good investment to learn.
If you're more of a self learner and just want to get certified to improve your chances on the job market then I'd go with winforms for the certification. You can pick up WPF when you need it. By the time you really need to have a WPF certification it will probably be easier for you because you've already used it.
WPF leverages XAML for the design/visual experience this is the same technology that Silverlight uses and in the future will be leveraged heavily by other aspects of .NET 4.0, specifically, WCF (web services) and WF (workflow).
I would highly recommend learning it if you have the cycles, however for certification purposes it might be easier to just go ahead and do the WinForms exam as WPF is quite different and in my experience had a bit of a learning curve (because of how different it is from WinForms).