We Keep Coding

c# Winforms MVC

I have never used MVC before and would like some advice.
I have actually already written quite a bit of code, but looking at it, it seems to be quite highly coupled between classes and there is a lot of code written on the actual main form of the winform. I am a University student, recently started on a 12 month placement, so do not have much real world experience.
My system is effectively a WinForm GUI that has, amongst other things, a treeview that is popualted at load via an event. And then when the user clicks on a node, it gets a datagridview from a dllplugin (which obtains the data from an Oracle DB via a perl script.
My question, is would MVC apply in this circumstance, and would anybody have any good advice/resources on how I can now, post-design to implement it?
Thanks.

The MVP pattern is more adapted to WinForms applications. Here's a nice article you may take a look at.

Received wisdom is that MVC is good for the web but has some constraints when operating in a desktop environment (I'm not sufficiently experienced in applying this sort of pattern in either context to make a worthwhile judgement).
The pattern that Microsoft (for one) are pushing for forms use is MVVM - which is Model View View Model - and it provides a similar set of benefits in terms of separation and testability. Even allowing that I could wish I knew more I can see what and why, especially if you're looking at WPF (and Silverlight) but in any context where you're trying to ensure separation.

The MVC pattern can work well with WinForms, see this question.
There are lot of related pattern to choose from; in the case of WinForms (unlike WPF) there is no clear winner.
Partly this is due to everyone having different aims, do you care most about:
Code reuse between Forms in the UI
Being able to support form the one UI system
Easy unit testing
Etc

My first .net web app - should I go straight to MVC framework (c.f. ASP.net)

I'm done some WinForms work in C# but now moving to have to develop a web application front end in .NET (C#). I have experience developing web apps in Ruby on Rails (& a little with Java with JSP pages & struts mvc).
Should I jump straight to MVC framework? (as opposed to going ASP.net) That is from the point of view of future direction for Microsoft & as well ease in ramping up from myself.
Or if you like, given my experience to date, what would the pros/cons for me re MVC versus ASP.net?
thanks

Have look here it will help you Choosing the Right Programming Model

If you need to work really close to the wire then MVC is a great choice. By this I mean, if you need to have very tight controls over markup then; while acheivable with WebForms; it is much easier with MVC. This would be common for applications that are targeting a public (e.g. internet) audience which might have a richer graphical experience. In contrast, if you're developing an internal (e.g. intranet) business application where graphical presentation is not as critical, then WebForms has a lot of really nice enabling capabilities that will allow you to move more quickly.
Don't get me wrong, you can make WebForm applications look really really nice, but you give up some control over the markup.
Very often ViewState comes into this kind of discussion. MVC will not have any ViewState so the on-the-wire footprint will be much smaller which translates to speed and bandwidth cost savings at some point. On the downside, making stateful applications with MVC can be more painful. In contrast, WebForms will carry ViewState by default and are inherently more stateful. This is typically fine for internal applications. Keep in mind that ViewState does not have to be sent over the wire... there are extensions that allow you to offload that to a local cache. I'm not favoring one over the other, but you should be aware of what each can do in this regard.
If unit testing is important to you then MVC is also a much better choice, as this is easier as well. This is totally acheivable in WebForms but requires you pattern your code behind correctly.
Security is not a major factor since much of setting up the IPrinciple and IIdentity occure in the HTTP pipeline via HttpModules, so either will do in that regard.
Another major factor in making your choice relates to your skills relative to the time you have to deliver... If you're not used to working in a stateless manner or coding standard web technologies (e.g. html, css, jquery, etc...) MVC will take you longer to do very basic things. With that said, once in place it will likely be cleaner, smaller, more testable, and faster. If you need to move very quickly there is a lot you can do faster in WebForms. WebForms also does a lot of heavy lifting with respect to markup so there are a number of details you can leave to ASP.NET.
I actually use both for a variety of reasons, and MS has stated they plan to continue support and development for both.

MVC is part of ASP.NET. You must mean MVC vs Webform to which the answer would be: coming from a Winform background, you will find webform easier to use. For the future, go MVC.

I used to work on desktop applications too, and never really got into web stuff. I didnt even (gasp!) knew HTML (yeah, that was my programmers shame). In my new job we were going to start a new application using ASP.NET MVC and I gotta tell you, I love it. HOWEVER I think you should only go with MVC if you are or you count with someone with good html/css design skills.
Html is easy I know (I've learned it know!) but I think its kind of hard to make nice designs with html and css, specially if you suck at designing and you could probably do prettier stuff using webforms, which is a little bit easier/similar to winforms.
Also, if you go the MVC way make sure you have enough time to learn it, since you are going to go a little bit more low level, gonna have to learn more of the little details, like the actual difference between post/get and all that stuff that is pretty much completely hidden in webforms. I would really recommend getting a book, I used this one Pro Asp.net MVC and really liked it.
Finally, if your page is gonna have interactive bits, or ajax-y things, if you go the MVC way you are more likely gonna have to learn javascript/jQuery too. If you go the webforms you can use the included drag'n drop ajax controls.

Coming from Ruby on Rails or other MVC based frameworks ASP.NET MVC is almost the best choice. (ASP.NET MVC is actually only the "VC" part, so you have to add an ORM of your choice. EF and Linq to Sql is the Microsoft way, NHibernate or other ORM's are the other way. One good quick start project is S#arp Architecture which uses NHibernate as the "M" part, or you can check out WHCM, which is a project built on S#arp Architecture and other good frameworks (it is considered an ASP.NET MVC best-practices demo project) ). ASP.NET MVC uses almost nothing from the WebForms package (the only exception I found is the AntiForgeryToken), so you'll loose nothing if you're unfamiliar with ASP.NET WebForms.
But as you said you have also made console applications, which ASP.NET WebForms resemble more.
If your project is new, I advise you to use ASP.NET MVC. If your project clearly separates the M-V-C part (like in S#arp Architecture, where they reside in different assemblies), creating a console application that uses the same business logic shouldn't be too hard. If your current project is to port a WinForms application to the web, then it might be easier to use WebForms.

I should get familiar with the language before using "fancy" stuff like MVC, because it's just way easier to learn when you could almost think in the language (but it's not necessary).

Horses for courses. If you're slapping together a quick app for someone, web forms is probably quicker and easier.
If you're building a long running enterprise app MVC gives you better testability a SoC.

Architecture for new ASP.NET web application

I'm maintaining an application which currently is just a web service (built with WCF) and a database backend. The web service is built in layers with a linq-to-sql data access part with core functionality in an own assembly and on top of that the web service assembly which contains the WCF code. The core assembly also handles all business logic rules (very few actually).
The customer now wants a Web interface for the application instead of just accessing it through other applications which are consuming the web service. I'm quite lost on modern web application design, so I would like some advice on what architecture and frameworks to use for the web application. The web application will be using the same core assembly with business rules and the linq-to-sql data access layer as the web service.
Some concepts I've thought about are:
ASP.NET MVC (or MVC-2)
Webforms
AJAX controls - possibly leting the AJAX controls access the existing web service through JSON.
Are there any more concepts I should look into? Which one is the best for a fresh project?
The development tools are Visual Studio 2008 Team Edition for Developers targeting .NET 3.5. An upgrade to Visual Studio 2010 Premium (or maybe even Ultimate) is possible if it gives any benefits.

Definitely dig into ASP.NET MVC2.
All of our projects are now being developed using ASP.NET MVC2. It's not just highly scalable. It's highly testable as well. Which leads to way better maintainable apps in the long term.
WebForms vs. MVC2 points - (speaking out of experience):
Scalability:
In our company we had a lot of applications using WebForms which then were updated and changed by us as needed by our customers.
I think your customer will be requesting more changes on the application in near future. Making calls to other services, and maybe you'll have to rework parts of the final product to match their wishes.
And with the upcoming Cloud Computing and the Windows Azure platform you'll probably need to keep up with your code.
ASP.NET MVC absolutely supports the concept of being able to scale up your application any time you want.
I remember one of our customers walking up on me asking me for an extension for their app (they have a member management system) and the feature would contain something like a link to export the current view as a csv file so they could do office stuff with it (mostly serial letters).
It wasn't really a big problem setting that feature up. (took around 2 hours including writing tests) - let's go to tests:
Testability:
Using WebForms we didn't really have much interest writing tests because it was a pure pain to do so.
I remember writing some tests to have at least some proofs but let's drop that topic.. (:p)
We had tests for our custom classes but we couldn't really test all the EventHandlers within the WebForms.
Our CodeBase is way cleaner and saver to use thanks to this testable environment. I just check out some of the code, modify it, run all the tests and: Oh, it broke on strange behavior! - Let's fix that again. Earlier, I remember sitting with my co-worker debugging and trying to find those bugs for hours.
With ASP.NET MVC2 we are now lacking tests!
We ask all kinds of people (even the non-Web ones) to provide test-cases we could feed into our TestSuite.
And yeah, there are some AJAX-Controls too:
AJAXability:
You asked about AJAX Controls and in conjunction with ASP.NET MVC I highly recommend you to check out Telerik ASP.NET MVC UI Controls.
If that isn't something for you, we also make extensive use of jQuery and jQuery UI
With ASP.NET MVC and the HTML Views, those libraries aren't just a pleasure to use, they just look amazingly beautiful.
There is no random-html-tag-id-value autogeneration anymore!
But what I like most is: You can finally really re-use your code again.
There is so much more to those frameworks than just that, there is the T4 templating system. Auto-Scaffolding for your ViewModels / DomainModels with the Html.EditorFor() method and of course there is a great and easy way to use the IoC and DI paradigms.
Assuming that you have asked the question with mostly .NET Framework related tags, you'll probably stick with it.
Just to keep the post complete, there are also other frameworks that are just as good (or even better):
Ruby on Rails
Django
CakePHP
And many many more!

There's also DynamicData which may be appropriate if you need simple CRUD access to your data.

The Web Service Software Factory (WSSF) might come in handy in your situation.
This will allow you to define your contracts (XML entity returned (if XML you choose), etc.) while designing the server/client communication using WCF (or standard Web Service communication protocol).
WSSF favors either ASP.NET MVC or ASP.NET MVP. A simple example of the MVP architecture is shown here, plus this article.
As for me, I often come with a hybrid-like architecture using a bit of both MVC and MVP, as both have different strong points which combined together fill each other's improvement points.

I'd also recommend looking into Silverlight.
http://www.silverlight.net/learn/

Just my opinion to use MVC on Client sites and WebForms inside administration pages(site)

Architecture for WinForms applications?

I have started a WinForms project a few weeks ago and as I did not really know what features I wanted, I just added them along the way. This now caused a horrible mess where my MainForm is a big ball of mud and where for example some important state changes are triggered by UI elements to the point I have to call the OnChange Event of a Control in order to change some state in the database.
In short: I've just started a new project where I want to take a better approach. I just don't know which would be the "good" one. In ASP.net MVC, I found the MVVM Pattern really useful, but on the Desktop, MVVM seems to be only intended for WPF, not for WinForms.
The other approach is a three-tier-architecture: I have my Database-Class which currently talks directly to the UI. I now create a new Static Class ("ApplicationState") that talks to the database and fires events to tell the UI "Hey, Something changed!". The UI would manipulate the State which will then handle the database persistence and again raise Events if the UI needs updating. The point here is that the ApplicationState class never modifies the UI directly, but that the UI subscribes to Events. That looks like a clean/"MVC-y" way of doing it, but maybe I am overlooking something here?
Basically my ultimate goal would be to have the UI completely independent from the database layer just to make sure I don't wire in business logic into the UI again.

Don't throw in the towel on MVVM - it's valid for WinForms as well. Basically, if you use data-binding, you have to make a decision about what your objects will bind to. Often, especially for more complex UI, you dont want to bind directly to your domain objects, you want to build specialized classes (sometimes wrappers) that your UI can bind to which provide everything the view needs (the essence of MVVM) and the technique works just as well with Winforms.
A good series on WinForms Model-View-Presenter approach can be found at
The Build Your Own CAB Series Table of Contents

What I would always go for (first) is to have a layered application
Presentation Layer (JUST UI and databinding logic)
Interface Layer to the Business Layer (defining the contracts for accessing the BL)
Business Layer implementation (the actual logic, data validation etc...)
Interface Layer to the Data Access Layer (defining the contracts for accessing the DAL)
Data Access Layer implementation
This organizes your application extremely well. Then I'd look for some MVC kind approach. I did not develop so much with WinForms, more with Asp.net and some Java Desktop clients (where I used MVC). WinForms works more with the .Net databinding approach (DataSource, DataMember,...). You should go for that approach instead of trying to force something other. I found that it doesn't match that well.
What's always useful is to lay out our UI logic into different controls (like UserControls in Asp.net). This facilitates reuse.

NDepend documentation comes with some pretty cool and advanced online blog posts, articles and white books concerning architecture of .NET code.
Advices on partitioning code through .NET assemblies
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
Also, if you want to continuously check that your UI code is independent from your database code, you can write easily some Code Query Language rules that will be checked live at development time in Visual Studio:
Keep your code structure clean

Just start writing unit-tests for everything you can think of. As some pieces will turnout difficult to unit-test because of tight coupling to the WinForms, separate them out. Clean. Wash. Repeat.

Nido framework is good. However it is just for your back-end architecture. It will give you a solid, flexible, and simpler back-end with t4template. It prove to be having a very good architectural pattern. Furthermore it can plug not just with WinForm but with any other (MVC ASP.NET etc) front-end too..
Then again RocketFramework is also good
Link1: http://rocketframework.codeplex.com
Link2: http://nidoframework.codeplex.com

Our rule of thumb is to lean towards MVC for most websites due to the stateless nature of the web. Unless you're trying to provide a very rich web experience and bring in silverlight, then you should go with MVVM. XAML goes hand to hand with MVVM and can be your smart client choice as well (or a nice MVCP pattern).
True MVC is almost impossible to uphold in any other circumstance due to the fact that controllers are suppose to handle all input. Most non web architecture has controls that will provide this for you. In fact, most say that ASP.NET MVC is a hybrid MVC anyways but it's very good in my experience.

Okay,
I found some nice answers above but as per my 4+ years of experience in winform, I can say that you can use dotnet remoting for this purpose. In simple words, you need to create one solution for your business logic and client side works and another solution for connection with the database which you can called as a server. Both solution should contain some common projects and then you can easily works on your application without worry about your database.
I would suggest you to read about dotnet remoting.
Hope, this answer is helpful.

Developing a new application with .NET?

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