We Keep Coding

c# Forms - MVC frameworks?

I need to develop a forms application with a DB backend. In future this may be linked to ASP.NET page. I was thinking of doing this as an MVC and reuse later.
So, What kind of MVC frameworks do you use?
I am interested in building forms quickly and any frameworks that link/bind control to database fields.

There are no really famous MVC frameworks for Windows Forms. There is probably a good reason for this - it's really difficult to implement MVC with Windows Forms due to the nature of the technology. I think you're much better off using MVVM with Windows Forms and I'm saying this as a huge fan of MVC.
Otherwise you need to give us more details of what you're doing and then we could probably offer some better advice.

This O/R-Mapping-Framework includes a Solution for the MVC and Command-Pattern, which is recommended for Desktop-Applications.
There is a Demo-Application which demonstrates a simple Win-Forms-Application.

In my knowledge there isn't a specific mvc framework for winforms, as for web applications (mvc2) . You'll have to implement the mvc (or better mv presenter) pattern by yourself. See this link http://msdn.microsoft.com/en-us/magazine/cc188690.aspx

MVC is really only a pattern to structure your code around.
If you are really going to take your app and port it to be available over the web later on then may I suggest that you code it as a WPF application using the MVVM pattern as this will involve less work in the long run.
Alternatively if use ASP from the start.

C# architecture for large application

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

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

How would you architect a desktop application in C# 3.0

I've created a simple desktop application in C# 3.0 to learn some C#, wpf and .Net 3.5.
My application essentially reads data from a csv file and stores it in a SQL server CE database. I use sqlmetal to generate the ORM code for the database.
My first iteration of this app is ugly as hell and I'm in the process of refactoring it.
Which brings me to my question. How would you architect a desktop database app in C#?
What are the best practices?
Do you create a Database Abstraction Layer (DAL) which uses the sqlmetal generated code? Or is the generated code enough of an abstraction?
If you use DAL pattern, do you make it a singleton or a static member?
Do you use the View-Model-ModelView pattern with the DAL pattern?
Apologies if this seems like a long open ended question, but I have been giving this a lot of thought recently.
I see a lot of examples on how to architect an enterprise n-tier app in C# but not that many on architecting standalone desktop apps.

I would start with the Composite Application Guidance for WPF (cough PRISM cough) from Microsoft's P&P team. With the download comes a great reference application that is the starting point for most of my WPF development today.
The DotNetRocks crew just interviewed Glenn Block and Brian Noyes about this if you're interested in hearing more from them.
Even better, Prism is not nearly as heavy as the CAB was, if you're familiar at all with that from the WinForms days.

The answer is "it depends" as always.
A few things to think about:
You may want to make this fat client app a web app (for example) at some point. If so, you should be sure to keep separation between the business layer (and below) and the presentation. The simplest way to do this is to be sure all calls to the business logic go through an interface of some kind. A more complex way is to implement a full MVC setup.
Another thing you may consider is making the data access layer independent of the business logic and user interface. By this I mean that all calls from business logic into the DAL should be generic "get me this data" rather than "get me this data from SQL" or even worse "run this SQL statement". In this way, you can replace your DAL with one that accesses a different database, XML files, or even something icky like flat files.
In short, separation of concerns. This allows you to grow in the future by adding a different UI, segmenting all three areas into their own tier, or changing the relevant technology.

Before architecting anything you should define requirements for your app.
It's a common error of beginner developers - starting writing code ahead of thinking about how it would perform. My advice will be to try to describe some feature of you application. It will help you to feel how it should be implemented.
As for useful learning resources I would highly recommend you to take a look at CompositeWPF it's a project designed specifically to teach developers best practices of desktop app development.

I'd start with Jeremy Miller's Build Your Own Cab series.
I was an early CAB adopter. I learned a lot from digging into that technology and reading all the .NET blogs about application architecture.
But recently I had a chance to start a new project, and instead of using CAB I went with StructureMap & NHibernate and borrowed some of the patterns that Jeremy uses (in particular, his way of handling event aggregation). The result was a really simplified, hand-tooled framework that does everything I need and I love working with it.
As to the specifics of your question: I use a Repository for data access. I initially wrote some ADO.NET code and used data readers and mapped my objects. But that got old real fast, so I grabbed NHibernate and was really pleased. The repositories use NHibernate for data access, and my data access needs are pretty simple in this particular app.
I have a service layer (exposed via WCF, Duplex channels) that utilizes the repositories. My app is basically client-server with real time updating (and I know your question was just about clients, but I would use the same technologies and patterns). O
n the client side I utilize MVP with StructureMap for IoC and some very simple event aggregation strategies for cross-class communications. I code to interfaces for just about everything. The only other thing I did was borrow from the CAB the idea of a flexible "Workspace" for dynamically displaying views. I wrote my own Workspace interface though and implemented my own DeckWorkspace and TableWorkspace for use in my app (these were really simple things to write).
A lot of my decisions in this most recent application were the result of experience and pain I felt using other frameworks and tools. I made different decisions this time around. Maybe the only way to really understand how to architect an application is to feel the pain of doing it wrong beforehand.

I would say yes, it could easily be structured towards smaller applications. There is a learning curve towards getting started, but honestly, it helped me understand WPF better than attempting to start from scratch. After starting a project with CompositeWPF and then starting another project without it, I found myself attempting to duplicate features of CompositeWPF on my own because I missed those features! :)

Compact Framework - Is there an MVC framework/library available?

I've found an article on this subject by a Microsoft employee, but has anyone implemented a more robust framework for this? Is there a lightweight framework for WinForms that could be ported easily? I'd like to get up to speed fairly quickly and avoid producing a framework/library of my own to handle this when someone smarter has already done this.
I haven't looked at the Mobile Software Factory from the P&P group, but I suspect it's kind of heavy. Is it worth a look?
Edit: I'm not looking for information on the ASP.NET MVC project. I'm asking about the compact framework 'WinForms' implementation, and how to implement MVC with that.

I personally think that the Mobile Software Factory doesn't hold much joy for CF.
We still use one part of it (EventBroker) at work and I'd like to even remove that part if possible (as it doesn't support generic events and you have to cast the arguments into their strong types from EventArgs). A sister project at work used it for part of their UI but had to rip it out due to performance issues (another big project, although that has additional performance issues of it's own as well).
The issue I find with the MVP framework that the P&P lib offers is that Forms and Controls OWN presenters instead of Presenters/Controllers owning Forms (who didn't read "It's just a view" : Pragmatic Programmer?).
This fits beautifully with MS's "Form First" rapid application development mantra but it sucks when you consider how expensive windows handles can be in CE (if you have a lot of them).
We run a very large CF application at work and we've rolled our own MVC framework. It's not hard to roll your own, just make sure you separate everything out into Controllers, Views, Business Objects and Services and have a UIController that controls the interactions between the controllers.
We actually go one step further and re-use forms/controls by using a Controller->View->Layout pattern.
The controller is the same as usual, the view is the object that customises a layout into a particular view and the layout is the actual UserControl. We then swap these in and out of a single Form. This reduces the amount of Windows Controls we use dramatically.
This + initialising all of the forms on start-up means that we eradicate the noticable pause that you get when creating new Windows Controls "on-demand".
Obviously it only really pays to do this kind of thing if you are rolling a large application. We have roughly 20 + different types of View which use in total about 7 different layouts. This hurts our initialisation routine (as we load the forms at start up) by a magnitude of about 10 seconds but psychologically most users are willing to accept such a hit at start up as opposed to noticeable pauses during run-time.
The main issue with the P&P library in my books is that it is a FF -> CF port and due to certain incompatability and performance differences between the two platforms you lose a lot of useful functionality.
Btw, this is by far and away the most comprehensive article i've ever read on MVC/MVP.
For Windows application (desktop or CE) I'd recommend using the Taligent Model-View-Presenter version without the interactions, commands and selections (e.g the controller/presenter performs all the work).

Neither of you (davidg or Kevin Pang) paid attention to the fact that he's interested in WinForms, not Web Forms. He wants a framework that pushes the Model-View-Controller design pattern (davidg, MVC isn't just the name of an ASP.NET framework) in a WinForms project using the .NET Compact Framework. He asked his question just fine.

There's also the OpenNETCF IoC framework (which I don't think existed when this question was asked) which is much lighter, but similar in object model to the P&P's Mobile Software Factory.

#DavidG and #KevenPang
MVC is not limited to a web technology, in fact the original smalltalk MVC was for desktop applications.
It works like this:
View = Client Form
Controller = Wraps up Client Events and marshals between View and Model
Model = Application Data and Business Logic
In pure Smalltalk MVC, the View is not limited to being a form, but can be any representation of Model Data...For example, if we had a Model that represented a spreadsheet, we could have the following views:
SpreadSheet View
Printer Friendly View
Icon View
etc, the Model would be the same, but the View would create a different output object in each case.
All that said, I don't know if such a framework exists for the .NET Compact framework, I just wanted to point out that MVC does not mean WebApp.

Take a look at mFly's Mobile MVC. I've never used it, but it's pitched as a reasonable MVC framework for the CF.

#davidg: "Why would you want MVC on Compact Framework?"
Why not? It's not like it's reserved for web dev, it's a pattern.

Edit: The above posters are correct. I saw MVC and immediately thought of web forms. My apologies. Feel free to disregard this. I'll leave my original message in place just in case anyone who is interested in web forms MVC needs the links. :-)
There are a couple MVC frameworks out there, neither of which are very "lightweight", but MVC is a pretty big shift away from web forms so that is expected:
ASP.NET MVC - This is Microsoft's attempt at an MVC framework. It is still in preview mode so use it at your own discretion, but several people are already using it in their production applications. You will find ample documentation on this with a simple Google search as it is becoming very popular amongst the .NET crowd.
Castle MonoRail - The MonoRail framework is an open-source MVC framework that has been around for quite some time and is in use on several production applications. It is definitely more flushed out than the ASP.NET MVC framework, but considering the amount of effort Microsoft is throwing at their MVC offering, I think will change relatively soon.