Personally, I'd design my app to take account of the Alpha nature. If EF isn't going to be ready then you don't have a lot of choice. No other freeware solution comes close to NH in my opinion.
In our company I've designed the apps so I have a formal repository that implements an interface in the domain later. This interface defines that has methods you can call but the repository implements them. This reverse dependency is wired together via an IoC product such as Spring.NET or Unity. Therefore I have a choice in the repository how I implement the method - I can use Linq-NH, which works in 70-80% of cases or, where it gets complicated I can shift to HQL. The domain layer doesn't care how the repository does it. Although it isn't "pure" and I don't really like it, I do expose a an IQuerable<T> Query property in the repository for those simple ad-hoc queries that Linq excels at, so I don't need a special method for every single simple thing I need to do. I also make sure my developers know Linq-NH isn't a fully featured Linq implementation (e.g. I can't get it to do joins) but as least I have an architecutre in place to work around any issues that crop up. I also have an architecure to swap to EF if I need to in 2010 / 2012 but I expect with NH 3.0 Linq will be fully featured and I won't really need to. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
