We Keep Coding

Which ORM does fit best here?

I need to choose an ORM for a project and I only have some experience with NHibernate. I have been reading Q&A from StackOverflow, and the most similar to my needs is What ORM for .net should I use?, but I would like to have an answer more adequate to the present products (the link is from 2009) and that also take into account some points of my project.
The easiest solution for me would be to use NHibernate because it is mature, feature rich and I have already used it, but I prefer to choose the best option for the project even if I have to "study" again.
The project is going to start as a core that communicates with SAP. The core has to support standalone and/or co-dependent modules, and each one of them may need to work with its own data from the database. The final step will be to implement the part of SAP that we use. The characteristics I need are the ones from the previous link and here are some more things to have in mind:
I would like to be able to split the data access layer so that a user with one or two modules won't need the whole thing.
A designer would be appreciated.
It will start with about 20-30 tables and, within a couple of years, that number will grow in several hundreds.
The amount of registers per table will vary from two or three to 150000+ (very few).
IT DOES NOT NEED TO BE A ONE PRODUCT SOLUTION. Combinations like NHibernate and Devart Entity Develop are also welcome.
The team for this project will also have students that will have to learn C Sharp and some of them probably don´t know exactly what an ORM is, so it would be great if it is simple or, at least, the basic stuff is not very complex (mixing tons of lambdas, reflection, extension methods, etc.).
The last one is not very important. I hope this is specific enough to avoid been closed (the question I link is still open).
EDIT:
-It is a desktop application.
-Documentation and comunity are also very very important.

The most popular ORM for .Net these days is Entity Framework. It comes from Microsoft, so well documented in MSDN style. And it fits your criteria.
I worked with NHibernate and found that documentation is patchy, inconsistent and sometimes missing. Most of the time I had to use docs for Hibernate which were not for NHibernate, just similar.
EF can do the same things and more than NHibernate, and the latest release have Migrations, which was missing (when I worked with NHibernate).

Consider it Dapper: dapper-dot-net.
Dapper is a pretty simple ORM, developed and used by StackOverflow.
There is a lack of documentation, but that is because of it simplicity. You can find some usage example in the project page or in some websites like this.

I know this is a pretty old question, but I though I would post an answer for anyone who lands here. Check out SQL Data. It is extremely simple to use, very powerful and fits all the OP's requirements.

Which options are ther to set up your 3-Tier system

Which options are there to make your 3-Tier System.
Client / Common / Server
Now we work with the entityframework and agatha. But are there other options to make a good 3-Tier system?
The agatha framework, makes for us the request/response on the common site.
On the server site the response will be filled in.
But are there other framework to do all that work for you? Or should you do it without such framework. And call at the server site stored procedure? Or with LINQ? With the agatha we query the repository's with some LINQ queries.
But i am wonna know if there are other ways to do the communication. Maybe there are other and better ways to do it.
I hope i get some usefull answer. Where i can read some new things.

Ultimately there is nothing in any of the Frameworks that you could not, at some level, do yourself. The Frameworks VASTLY simplify your life, however.
For calling the DB, you can use System.Data classes, for calling out to the UI (from middle-tier) you can use BCL classes, etc.
Alternatively, there are, indeed, additional frameworks that do a lot of that for you. NHibernate (in place of Entity Framework), ASP MVC for end-to-end, etc. While no two frameworks are exactly the same, most of them (now) have some core functionality that you can always expect. My recommendation would be to go to Google (or bing, or yahoo, or wherever) and search for things like "Object Relational Mapping" "User Experience" and browse through what you find.

I know you can everything without any framework.
But not everything is good. Somebody says work with stored procedures. Others say to use repository's en use linq to sql to get the right information.
And offcourse the frameworks help you. But i don't have any experience with other frameworks. So i can't say which framework works good.

Is Telerik openaccess ORM worth learning?

I have just won 1 Telerik Premium Collection for .NET Developer with subscription (lucky me!) and was wondering whether the OpenAccess ORM is worth learning? Has anyone thrown away their open source variant and are now using the Telerik ORM tools instead?
Are there any benefits from using the Telerik ORM tools instead of an open source variant?
Any thought suggestions?
BTW I can't wait to start using their RadControls for ASP.NET AJAX!!

I'm a happy telerik customer for more than 5 years. I used their ORM only in one solution and never used an open source ORM.
Throw away the existing one?
NO - if you have no problems and the thing does what it should do I wouldn't change.
That has nothing to do with quality or other aspects of telerik ORM.
It's just a matter of fact that using a new product means to learn new things, solve some solved things again in a different way and so on.
BUT - if you have problems (or must make compromises) with your current product it's sure worth to give it a try.
Without knowing other ORMs I have one clear point why I would try telerik ORM.
It's their (telerik's) outstanding support.
None of my other vendors offers / does what telerik does.
Simply take a look at their forums http://www.telerik.com/community/forums.aspx and you'll see what I mean.
You have a problem - they solve it; and that with very fast response times.
And that's a point you should think about when making a decision about ORM (or any other kind of product).

This is an older post, but I thought I would weigh in.
We recently started using Telerik's SiteFinity product for a client website. It is a very good, developer-oriented tool for creating a web content system without the size or expense of SharePoint or something similar.
We also went with a Cloud solution as Telerik's ORM supports Azure, so thus so does SiteFinity - which uses OpenAccess (ORM) to communicate with its database.
I was very impressed with the speed and flexibility of it all, being my first Cloud (Azure) development project. Telerik's customer support and personal attention is beyond reproach. I have been using Telerik products for years and was not surprised how well it worked.
Two days before the site was to go live everything bombed with a very inexplicable .Net error. As it turns out Microsoft announced they were upgrading their Azure SQL servers starting July, 2011: "This upgrade is also significant in that it represents a big first step towards providing a common base and feature set between the cloud SQL Azure service and our upcoming release of SQL Server Code Name 'Denali'."
(http://blogs.msdn.com/b/windowsazure/archive/2011/07/13/announcing-sql-azure-july-2011-service-release.aspx)
By its very nature, Cloud servers are upgraded and moved around behind the scenes so you don't have to mess with it. OpenAccess failed to take this into account however, and when our SQL Azure server group was upgraded OpenAccess failed to recognize its version and bombed.
Telerik, of course, was very quick about releasing a patch - but it still took them a few days. We couldn't wait that long, unfortunately, having already lost quite a bit of time just trying to figure out what was going on. The practical result was that I got to work nonstop for two days with no sleep to move the whole thing into a regular .Net solution with Entity Framework 4 as the ORM.
So to answer the question: Is Telerik ORM worth learning and / or better than an open source solution? I agree with the above statement that if you already have an open source solution, it is working well, has good performance, and is intuitive to develop against - absolutely stick with that.
The value of open source is the community that supports it and your ability to make changes to the underlying system if need be. Had my project been based on an open source ORM, I could have changed the code to default to the most recent version of SQL if it finds it is working with a version higher, and problem solved - sleep had.
The value of a product like OpenAccess ORM is that it is in competition with other products, open source or otherwise, and it has to: Perform Well, be customer oriented, have a manual (very important), and be easier than doing it yourself or learn an open source system that may or may not be very intuitive.
Throw in that Telerik's support is top notch, and I would say you could do worse - as long as you are willing to give up some control and have to wait for upgrades / patches to handle things like I described above.

First off I want you to know that I am not Telerik evangelist...
We did moved away from Telerik's ASP.NET AJAX controls only because we desired greater control over the look and feel of our UI (we still use the controls for quick internal solutions), but I must say their products are excellent given the right conditions. Our web product team started to use the Open Access ORM for our solutions and honestly we never looked back. The first reason that comes to mind to choose a Telerik solution is grade A support which has never failed to provide a resolution to a problem regarding any of their solutions with in 24hrs usually including sample code... Although I can usually dig through blogs for hours to find solutions for most of my issues regarding Microsoft technology I must say it is nice to have support when we need it.

I would certainly recommend using the Telerik Open access ORM. I have used Telerik products (eg telerik Ajax/Silverlight) for a number of years and they are best in class and the technical support is second to none. The company makes money by providing software that works.
Unfortunately this does not apply to open source since by definition anything can changed without proper control. All it needs is one duff developer and an entire suite can be rendered useless.
In order to use the products correctly, swiftly, and efficiently, it is necessary to be a highly competent web developer.

I'm one of those people that won a license at a users group meeting. Thankfully I got to experience how crappy this software is without paying for it.
I never got to test the ORM capabilities because the Visual Studio integration failed. Any click on the Telerik menu in VS threw an exception. And the VS item template that was supposed to be installed was not there, so I couldn't even begin to test the functionality.
Don't be fooled by the pretty designer screenshots, they can't even get the installer to work correctly.

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! :)