I'm writing a Windows version of my Mac app (C# Winforms) and would like some advice on what design pattern to use.
My Mac app uses an MVC pattern with Core Data for storage. This is a simplified diagram of the models and relationships:
The desktop app collects logs on a background thread and periodically uploads them to my web app. The database is used to store both the user's account information and logs, and the app has a 3 views to display (and collect) the user's data.
I've done some reading and it seems that MVP is the recommended design pattern for WinForms apps, but I'm not sure how to proceed from here. I think that my app is simple enough to write without using an external framework like MVC# but as I have never made a WinForms app before I am only speculating.
Can someone recommend the best way to go about this?
Patterns are really just guides as to what problem it is trying to solve. Where an MVC would work well for a web app that relies on pages and redirects etc a winform app can benefit from using MVP.
Having said that the two patterns are siblings of a wider UI pattern and even according to Martin Fowler the MVP pattern can be further split. Look at his article to get a good feel for the appropriate pattern. He has broken the MVP to Supervising Controller and Passive View. Even the new MPF MVVM pattern is actually based on the PresentationModel pattern.
I would say look at the patterns and see what fits rather than trying to use a pattern because you used it in another scenario.
In my experience for a winforms application (which supports nice databinding) you can use MVC with a supervising controller pattern. Read through this question What are MVP and MVC and what is the difference? & http://codebetter.com/jeremymiller/2007/05/25/build-you-own-cab-part-3-the-supervising-controller-pattern/
You should take a look at Jeremy Miller's Build your own cab series :
http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/
Start to work on it, do some screen mockups, do some design, write some code.
You could start with a few small prototype, try out different design. Don't go too far in your exploration phase so that you don't hesitate to throw it away and start over if you need.
Try to keep your choice open as much as possible, don't paint yourself into a corner, and delay this decision until your really need to choose one way over another.
By then you will probably have a much better Idea of what you need.
Related
I am watching some tutorials that go over some of the basics of C#. The guy teaching them is setting up the projects using a domain layer, a persistence layer, a presentation layer, and is using web forms. In the past i had taken a class on PHP with MVC but it has been a while. I don't remember anything about the way he is setting these projects up. Is this set ups something specific to web forms or C#? Is it something i need to know moving forward if i plan to work with the MVC model?
EDIT: Is this pattern used in MVC?
It sounds like you've found a good tutorial.
The average MVC tutorial puts everything in one project, puts the business logic in controller methods and skips using domain models altogether. Then again, the average MVC tutorial doesn't reach beyond a simple "Hello World" or "TODO App".
Relevant search terms about these constructs, which should be explained in the tutorial (if not, find another one), are "layered design", with implementations such as N-tier and N-layer. If you search on that, you'll find plenty of resources explaining what it entails and why you should use it.
See for example Martin Fowler's arcicle on PresentationDomainDataLayering.
It's definitely not necessary for learning WebForms or MVC, but it helps building scalable, testable, reusable application components.
These are part of SOLID Principles and Separation of concern. They are a methodology that can be applied to pretty much all Languages and are good principles to follow.
Keeping in mind what CannibalSmith once said - "All the answers are saying "WPF is different". That's a huge understatement. You not only have to learn lots of new stuff - you must forget everything you've learned from Forms. It's a completely new way of doing UI."
.. and having many years of experience with visual Windows desktop applications development (VB6, Borland C++ Builder VCL, WinForms) (which is hard to forget), how do I quickly move to developing to say well-formed WPF applications with Visual Studio?
I don't need boozy-woozy graphics to give my app look and feel of a Hollywood blockbuster or a million dollar pyjamas. I always loved tidiness of standard Windows common controls and UI design guidelines, end even more I enjoyed them under Vista Glass Aero Graphite sauce.
I am perfectly satisfied with WinForms but I want to my applications to be built of the most efficient and up-to-date standard technologies and architectured according to the most efficient and flexible patterns of today and tomorrow, leveraging interface-based integration and functionality reuse and to take all advantages of modern hardware and APIs to maximize performance, usability, reliability, maintainability, extensibility, etc.
I very much like the idea of separating view, logic and data, letting a view to take all advantages of the platform (may it run as a web browser applet on a thin client or as a desktop application on a PC with a latest GPU), letting logic be reused, parallelized and seamlessly evolve, storing data in a well structured format in a right place.
But... while moving from VB6 to Borland C++ Builder was very easy (no books/tutorials needed to turn it on and start working) (assuming I already knew C++), moving from BCB to WinForms was the same seamless, it does not seem any obvious to me how to do with WPF.
So how do I best convert myself from a WinForms developer into a right-way thinking and doing WPF developer?
Read this questions:
How to begin WPF development?
Is there a WPF Cheat Sheet outhere?
Learning MVVM for WPF
Learning WPF and MVVM - best approach for learning from scratch
MVVM: Tutorial from start to finish?
Download and work through this Microsoft tutorial: Southridge Hands-on-Lab
Check this videos:
Mike Taulty's series of videos
Jason Dolinger on Model-View-ViewModel
And after that, take a look at StackOverflow questions tagged with both wpf and mvvm
Keep in mind that MVVM seems suited only to single window applications.
I dived into WPF based on inexperience and general recommendations that it would suite better a kiosk project, especially one where the customer has given me photoshop images of all the application screens. Having cool graphics was a requirement for this project and I liked the vague resemblance of WPF with web development.
I found out a few downsides
1) there is no such thing as an official MVVM toolkit. There are a lot of them, all backed by an individual. A shot at a toolkit by Microsoft has been put on the back burner one year ago and there is no VS2010 support.
2) programming a multi windows application, sort of a simple wizard with back and forward, is plain nightmare. I got out of this with a clean design defining a delegate for each UI action and a command for each business action, but still I think it is too much involvement with a framework to be justified, and you cannot show the result of your tests to this customer expecting excitement.
3) You give up the habit of double clicking a button and adding some code. This leaves a nagging feeling of using the IDE against its nature. Basically you use Visual Studio as a text editor and an interface designer, still with a great help from the tool.
The upsides, so far are:
1) defining visual components is very flexible, fast and easy and you can choose between VS and Expression Blend. Animations are simple to create.
2) data binding simplifies the application. You define a DataContext and bindings and do not have to move data from the business logic to the interface yourself, as long as you have a property for everything that must be displayed.
3) You can reduce the amount of business logic in the interface to zero. It is easy to separate the application behaviour from its looks, so you can skin your interface in ten different ways with little effort and test all of your logic without opening a window.
4) you leave a door open to going with Silverlight if they ask you.
My conclusion is that if you have an MDI application in mind you might find yourself in big trouble. You should be aware that, if you choose WPF, you are ploughing ground for future generations rather than getting on a train that will get you there fast and easy. There is no established way to do things, especially those that are not covered by demos.
Toolkits, all things considered, are not so important and each of them will serve you well. In fact a couple supporting classes are enough to start and there are no fancy wizards, it is up to you to follow conventions.
You might even make your own if a few hours, once you understand what is involved in the logic. The downside is that you will have to really understand it well to bend the application your own way.
As I said above, I had to learn a lot just to show a new view when they click a button keeping the code clean. Take the time to see the videos cited elsewere on StackOverflow it will save you time.
if you are looking for books just look at this previous post
What WPF books would you recommend?
Having got into WPF this year, the most important thing for me was learning how to use the Model View View-Model pattern for separating the view from the app logic. As a general rule of thumb if you find you are placing a lot of code in the code behind for your view then you are "doing it wrong".
I found that coming from a WinForms background I was putting in lots of event handlers and doing stuff in my code behind. As I became familiar with MVVM and WPF features I found I was able to remove the bulk of my code behind and replace it with views binding to view-models.
It was articles like this one from Josh Smith that helped get me started on the MVVM path:
http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx
Once you have started to get the hang of displaying data view MVVM bindings, have a look at commands and specifically the ICommand interface. They are the main mechanism by which actions from the user triggers operations to execute. So rather than having a OnClick handler for buttons, you bind the Command property of the button in XAML to a property in your view-model that exposes an ICommand implementation.
My 2c - Donovan
Try this smashing hit.
Windows Presentation Foundation - Unleashed By Adam Nathan
(source: adamnathan.net)
Any good resources for setting up a Windows Form with C#? Looking to create my first database application using C# and VS 2008. Thanks any advice is much appreciated.
http://windowsclient.net/learn/ has a lot of articles on Windows Forms, even though it's focus has recently shifted towards WPF
Well for a start off, use a good pattern (I found this the most important thing for WinForms apps, as the code soon grows to the size of Susan Boyle) - at the moment I like the MVP (Passive view or Supervising Controller) pattern. Links below are some of the best I've come across:
http://www.c-sharpcorner.com/UploadFile/rmcochran/PassiveView01262008091652AM/PassiveView.aspx
http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-own-cab-series-table-of-contents.aspx
As for Windows forms themselves, they're pretty straight forward with the not so obviuos pit falls - just make sure you de-register any events you register (mem leaks...)
But there is a good site (ahem codeproject ahem dot ahem com) with lots of guys on there who are just genius's
Check out anything by Sacha Baber, I'm working my way through this myself ATM:
http://www.codeproject.com/KB/cs/AutoDiagrammer.aspx
I would take a look at MVC or MVP to make your life easier and make testing a lot simpliar. Here are some good starting points:
What are MVP and MVC and what is the difference
Selecting a MVC MVP implementation for a Winforms Project
Implementing MVC with Windows Forms
There are some nice easy tutorials on MSDN to get you started on Windows Forms. How to: Create a Windows Forms Application is a nice introduction to building a basic Forms application. Then you could move onto the Walkthrough: Simple Data Access in a Windows Form for a little bit more advanced with some database interaction.
As you are going to be creating a Database application and interacting with SQL Server I would also consider looking into LINQ to SQL: .NET Language-Integrated Query for Relational Data. This will heavily reduce the complexity of your database interactivity. It will also automatically create ready-to-use Business Objects based on your Database tables which reduces the amount of coding you will need to do in your DAL. Scott Gu's blog article Using LINQ to SQL (Part 1) is a great starting point for learning L2S for the first time.
Also as others have already suggested, I would advise you read up on some design patterns to follow when implementing your application as it will probably help you in the long run when your application begins to get more and more complicated.
it seems like your mixing your terms up a bit.
Form is a window for a application, visual studio comes with a designer for those, that you can design your UI using drag and drop
For the database the microsoft sql server comes with a UI and a designer called Sql Server management studio. That allows you to design your entire database
What are the fundamental techniques to make most part of my C# source code UI independent?
For example, I would like to write my source code for Winforms desktop application which I shall be able to plug into asp.net web application or a WPF application with very minor changes. I.e. I shall be able to use the same source code irrespective of UI technology to make it future-proof.
I know CSLA framework can do that.
But if I don't use CSLA (it takes some time to learn a new framework and at present I don't have that much time to spend on it), what points should be taken care of to achieve this kind of ability in my C# code?
Can you give me an example? I already use Business Objects and layering technique in my applications. But even so I have seen that it needs a lot of coding to plug my code to new UI technologies.
Please do not provide me with any superficial answer.
The best way to do UI independent coding is to seperate the logic from the presentation. Take a look at the MVC pattern.
This is more of an discipline issue with your design rather than a framework issue. A framework can't not force you to design properly. It can make things easier for you if you design the app properly, however there are always ways around the enforcement of it.
To make your code UI independent, put the logic that is not dependent upon UI into a separate layer or assembly. Separate logic from presentation. It's what all the patterns like MVC, MVP, and MVVM follow. It's such a fundamental piece of software structure that it should be ingrained upon you; if it's not, make it so.
Separate logic from presentation. Learn it. Live it. Love it.
Edit:
Can you give me an example? I already use BO and layering technique in my applications. But even so I have seen that it needs a lot of coding to plug my code to new UI technologies.
Please do not provide me with any superficial answer.
I see that you have edited. Allow me to elaborate:
There's no getting away from some logic that is UI-dependent. UIs are not a shell; they still have logic and functionality. But that functionality should only be geared toward user interaction. Display data. Gather data. Fancy graphical tricks and animations, if your preferences lie in that direction.
The rest goes to the business layer, and that stuff can be reused. If you layer properly, you can avoid having to rewrite your core functionality every time you write the program for a new UI framework.
But you still have to rewrite the UI stuff.
If you're building a multi-tier application, your business logic, data access, etc should already be separated into classes that are completely independent of your UI. Repurposing those libraries for a different target platform - desktop vs web, etc - should be a simple matter of referencing your existing libraries from your new application.
This is a fundamental rule of software development. Although patterns and frameworks like MVC, etc enforce this more stringently, it's ultimately up to you to design your application correctly. This sort of task doesn't require learning a new technology - just common sense and a tiny bit of experience.
Check out Martin Fowler's excellent article on this topic.
GUI Architectures, Including MVC, MVP, MVPC
Take a look at the explanation of MVVM(Model-View-ViewModel) at MSDN Magazine. MVVM is widely used for WPF application development.
I am familiar with MVC/MVP though my question is simple, I'm about to program a simple Instant Messaging software when the engine and communication part is an open API. so my software will have about 3 forms, a splash screen with login details, the options form and a main form with all the functionality like: Friends List, Send message, Received messages (tabbed), search user, etc.
In UI perspective, its important for the GUI to be in 1 form in my application.
So my question is, for the only complicated form that I'm going to have, is it necessary to implement an MVP design pattern or in this case its better to just go straight forward and put all the logic in 1 place?
THANKS
Janalopa!
I think that is always best to have a separation of concerns, particularly in the GUI.
My 2 cents worth is to always code in an MVC way. If it's worth coding it's worth coding well.
Ask yourself whether you can see your application growing past the current spec? It's going to be easier to code against an mvc framework than any other.
Anyway, MVC! :)
If you wish to expose an API to your web app, you definitely benefit from a clear separation of concerns. If MVP or another pattern is the right way to go is up to you, but you should try to have your app as loosely coupled as possible, so that you can
a) test it
and
b) expose it at whichever level that feels appropriate.
For example, you might want to start with writing your own chat form that posts and gets updates from a DB. If you have a loosely coupled server side app behind it, you can choose whether to expose the chat at the repository level, service level, controller layer or with a separate API layer that interacts with the same interface as your own UI.
EDIT: As a final comment, if you're starting with a new project a chat is definitely much easier to implement in ASP.NET MVC than WebForms, as MVC is in many ways easier to work with ajax calls and updates.