Develop Reference

C#/EF for Intersystems Cache

My background is more in C#/.Net, and have now been offered to move to Intersystems Cache. I haven't found any recent posts on this so unless I missed something here goes:
From what I understand Cache has some mapping for ADO.NET/.NET, but is there something out there so I can use Cache for the DAL and C# for the BL/front end (like ASP.NET MVC)?
Is there a port somewhat similar to Xamarin, that allows one to write everything in C#, using Visual Studio?
I haven't started with Cache yet, but from a brief glimpse it looks somewhat similar to C# being string based and slightly similar approach to interfaces and implementation.
Thanks

Simply put: no.
However, you can use the provided DLL (InterSystems.Data.CacheClient.dll) and the reference (InterSystems.Data.CacheClient) to establish an ado connection to cache. From there you can use SQL to get your data or call a stored procedure from cache. (I'm still researching myself.)
Here's a little tutorial for a c# front-end. (a bit old though, like cache)
http://www.windowsdevcenter.com/pub/a/windows/2006/03/28/oop-c-meets-cache.html?page=1
And some documentation: (this really helped me out)
http://docs.intersystems.com/documentation/cache/20131/pdfs/GBMP.pdf
Good luck and happy coding!

Yea, this is a late response, but here's something that may help, if you're still interested.
I remember back in 2009, Intersystems came out with a .Net Gateway where the Cache developer would create a DLL for you to use to call the different routines and globals. I think that has since been kaput. So I gave up and went with a linked server (static table created by a routine's nightly build) in MS SQL.
Recent searching led me to a link to a framework which I am currently looking into. I haven't tested it yet, but it is a "LinQ API to work with Caché Globals from .NET Entity Framwork"
You may also want to take a look at Caché eXTreme and the samples provided. I'm hoping to implement one of the two (or both) in order to complete a project I'm working on.

Actual implementation of StackForm MSDN recommendation for Compact Framework

I'm looking for an actual implementation of StackForm recommendation. It can be a framework, API or any light-weight, Compact Framework-compatible library.
It's not too complex to implement that idea, and I did in the past a couple of times, but I'm friend of not re-inventing wheels and maybe someone or group did an open sourced project implenting a generic navigation manager in order to create Compact Framework Forms application using this approach or any other similar to it.
FormStack explained on MSDN:
http://msdn.microsoft.com/en-us/library/aa446546.aspx#netcfuiframework_topic5
Thank you in advance.

I rewrote the MSDN Form Stack (originally written in 2003) in 2009 using an IoC container. Here's the blog entry. Not sure what else you're after - both examples provide a basic and generic mechanism for Form navigation.

NHibernate (or other worth recommendation ORM), real life example?

I'd like to learn database applications in C# and I'm about to select some framework. I heard many recommendations of NHibernate, however I haven't decided yet.
Anyway, I'd like to know if there's any real-life example (with sources) of NHibernate in C#, to learn best practices etc.? I know all of them are probably covered in the docs, but working example helps a lot understanding the proper development pattern.

Check out Ayende#Rahien, there's a lot of blog entries on NHibernate there. Another good source is NHibernate Forge. To get you started this would be especially helpful: NHibernate Getting Started Guide. Finally here you can find a downloadable working example of a NHibernate project based on the Northwind database.

The open source project S#arp Architecture is so far the best example I'm aware of for NHibernate:
S#arp Architecture
Even if it feels sometimes a little bit overdesigned, it follows best practices in implementing NHibernate in a multi-tier architecture.
I personally learned a lot about ORMs and good loosely coupled architecture going through
the code of the project.
Another worthwhile article about NHibernate can be found on CodeProject:
NHibernate Best Practices

Real life example: Orchard uses NHibernate, Fluent NHibernate and Linq To NHibernate for data access. It is an opensource CMS build by Microsofties. Source code is available at CodePlex.

NHibernate is a very solid ORM which allows you to create POCO classes, keeping your domain model very clean and allowing easier testability.
Entity Framework is improving rapidly. The UI tools in EF4 are okay for small applications but it is difficult to manage that kind of development with version control, rapidly changing DB schema etc. With EF4 Code First approach (in CTP stage at the moment) EF4 will will be much more attractive.
I have used LLBLGen in past with great success.
For beginners, Webmatrix can get you started very quickly. Check Rob Connery's video on how to use it with testing framework here

As others have said, NHibernate is a solid framework to work with. It's quite mature and has a lot of features that let you control exactly what will happen to your date.
That said if you're just starting out with database programming you may also want to consider LinqToSql. It's not nearly as powerful as NHibernate, and it has been more or less EOLed. However, what you give up in power you gain in simplicity. It will allow you to get a basic database application up and running probably within minutes and allow you to experiment as you first learn. Despite the simplicity of getting your first app up and running it's still powerful enough to be used to build something like Stack Overflow.
Some good Linq to Sql beginner resources:
NerdDinner
ScottGu's series: Using LINQ to SQL (link is to part 9 because that has links to 1 through 8 at the top). Although this one doesn't have an application download (best I can tell) it basically walks you through building an app.
If you have your heart set on learning NHibernate, you can also start with the NerdDinner tutorial linked above and take a look at Ayende's writeup on porting it to NHibernate as well as a series on mapping NerdDinner with NHibernate. There's also a series of articles on using NHibernate in a WPF application (most other tutorials focus on web apps).
Resources:
Ayende's Reviewing NerdDinner and Reviewing NerdDinner: The Select N+1 pitfall
NerdDinner with Fluent NHibernate Part 1 - The domain model
NHibernate and WPF (again, links to part 4 that has link to parts 1 - 3).
One thing I can't emphasize enough is once you get past the initial "cool...I can talk to the DB" phase, grab a trial license for an appropriate profiler (list of profilers at the top) for your platform. It will let you see what exactly your ORM is sending to the DB. It can be very valuable for learning how what you're doing gets translated into SQL as well as troubleshooting bugs you run into.
Regardless of which path you choose you should also take a look at Data Access Practices Using Microsoft .Net: A Nerdly Comparison and Data Development GPS: Guidance for Choosing the Right Data Access Technology for Your Application Today. Although those only cover Microsoft technologies, it'll give you a high level overview of what's available out there and when it may and may not be appropriate for your projects (in the future).

Take a look at NHibernate addins project http://code.google.com/p/unhaddins/
Though this is not real life production example, the sample applications there are pretty close to real life applications | scenarios. The examples there are written by well known and respected programmers and they show some serious OOP and design patterns skills. This is definitely not for beginners.

What is the best NHibernate cache L2 provider?

I've seen there is a plenty of them. NCache, Velocity and so forth but I haven't found a table comparing them.
What's the best considering the following criterias:
Easy to understand.
Is being maintained lately.
Is free or has a good enough free version.
Works.

I can't speak for what's best or worst, but I'll throw in my experience with NCache in case it helps.
Disclaimer: NHibernate and I had some disagreements, we have since gone our separate ways :)
The Good
The performance was great
The support was great, it's well maintained (I'm speaking to status as of ~6 months ago)
It has a free version (caveats below)
It worked as well as possible, but I had issues with the base level 2 cache provider implementation...but this was a problem on the NHibernate side with HQL, not the NCache side.
The Bad (For reference look here)
The free version had it's limitations, they are strategically put there no doubt, but for our project ultimately we couldn't use the free version because of some key features not available. The below restrictions are on the FREE version.
Key Based Dependency is not included
None of the database dependencies are included
No 64-bit version
Those were the sticking points on 2 different projects for me...however aside from those, no problems and I was happy with the simplicity of install and configuration. If the above aren't sticking points/requirements for you, I do recommend giving it a shot. It took me less than 10 minutes to get a server up and functioning as our L2 cache.

When NOT to use the Entity Framework

I have been playing around with the EF to see what it can handle. Also many articles and posts explain the various scenarios in which the EF can be used, however if miss the "con" side somehow. Now my question is, in what kind of scenarios should I stay away from the Entity Framework ?
If you have some experience in this field, tell me what scenarios don't play well with the EF. Tell me about some downsides you experienced where you whished you would have chosen a different technology.

The Vote of No Confidence lists several missteps and/or missing bits of functionality in the eyes of those who believe they know what features, and their implementations, are proper for ORM/Datamapper frameworks.
If none of those issues are a big deal to you, then I don't see why you shouldn't use it. I have yet to hear that it is a buggy mess that blows up left and right. All cautions against it are philosophical. I happen to agree with the vote of no confidence, but that doesn't mean you should. If you happen to like the way EF works, then go for it. At the same time I'd advise you to at least read the vote of no confidence and try to get a rudimentary understanding of each of the issues in order to make an informed decision.
Outside of that issue and to the heart of your question - You need to keep an eye on the Sql that is being generated so you can make tweaks before a performance problem gets into production. Even if you are using procs on the backend, I'd still look for scenarios where you may be hitting the database too many times and then rework your mappings or fetching scenarios accordingly.

One potentially big issue: Entity Framework 1.0 does not support persistence ignorance. This means that your business layer has a dependency on your data access layer.
If your entire application will be hosted in the same process (like a website on IIS) then this is no problem.
If, however, you have a need to remote your entities (to a Silverlight or Windows Mobile client for example), then your entities will not easily serialize across the wire. You will have to create separate data transfer classes to send your entities across the wire, and additional logic to marshal data between your entity classes and the DTOs.
Edit: spelling.

I'm also just at the 'playing around' stage, and although I was worried about the lack of built-in persistence agnosticism, I was sure there would be a "work-around".
In fact, not even a work-around in an n-tier architecture.
WCF + EF
If I've read the article correctly, then I don't see any problem serializing entities across the wire (using WCF) and also the persistence ignorance isn't a problem.
This is because I'd use PI mainly for unit-testing.
Unit Testing is possible! (i think)
In this system, we could simply use a mock service (by wrapping up the call to the service in ANOTHER interface based class which could be produced from a factory, for example). This would test OUR presenter code (there's no need to unit-test the EF/DAL - that's Microsoft's job!) Of course, integration tests would still be required to achieve full confidence.
If you wanted to write to a separate database, this would be done in the DAL layer, easily achieved via the config file.
My Tuppence Worth
My opinion - make up your own mind about the EF and don't be put off by all the doom and gloom regarding it that's doing the rounds. I'd guess that it's going to be around for a while and MS will iron out the faults in the next year or so. PI is definitely coming in according to Dan Simmons.
EDIT: I've just realised I jumped the gun and like a good politician didn't actually answer the question that was asked. Oops. But I'll leave this in in case anyone else finds it useful.

Not all data models map nicely to application Entities. If the mapping isn't relatively straightforward, I'd skip the Entity Framework. You'll find yourself doing handstands to make it work without any clear benefit.
Anders Hejlsberg had some interesting comments about object/relational mapping here.

Since EF does not support POCO, it can be difficult to write good unit tests against. That was one of the knocks against it in the Vote Of No Confidence.
If you're wanting to write good tests, EF will raise obstacles. You can work around them, but it is non-trivial.

Though both SQL CE 3.5 SP1 and Entity Framework 4.0 Beta 1 both support Identity Columns, using these two products together (at least up to the versions listed), Identity Columns are not supported. You will be required to set primary keys on your own.
Other than that, I've been enjoying EF with SQL CE.