As Mohamed said, you will have a longer start up time, but this will be the only noticeable effect from your high table count. Caching the configuration will help, especially in development.
Since you already have lots of T-SQL queries, and I assume those have been tuned and work well, you should check in to NHibernate's named queries. This allows you to declare each SQL or HQL (Hibernate query language) query in a mapping file. This means the queries can be parsed, error-checked, and compiled at configuration time. In my opinion, this is the best option, especially when combined with the "Enhanced Query Objects" (EQO) explained in a recent post on Fabio Maulo's blog. It's very powerful and easy to test. LINQ queries must be compiled at run time. You can use Jose Romaniello's LinqSpecs project to help make composable and testable where clauses, but it's still not as powerful as EQOs. Of course, you can mix the two. You can use SQL or HQL in your DB-only queries and hide LINQ queries inside EQOs when you also need to reuse that LINQ specification on in-memory objects. As for using any part of NH 3, including the new LINQ stuff, don't worry. Many people are using the trunk in production already and by the time you complete your porting, NH 3 will surely be released. - Jason On Wed, Jul 14, 2010 at 1:56 AM, Mohamed Meligy <[email protected]>wrote: > NHibernate is fine for dealing with this number of tables. Typically the > number of tables affects only two things: > > - Design time support, if your ORM has a designer that shows all tables > Of course this is not the case with NHibernate. No designer! So, you should > not have the issue at all. > (BTW: This is a known major issue with other options like Entity Framework, > going near q00 tables makes designer performance go down, also, this is not > a problem in some professional 3rd party designer-like tools like LLBLGen, > and not an issue of course in LLBLGen ORM itself) > > - Startup time: Reading the tables metadata in run-time when the > application starts > This will be your main issue I guess. It'll take quite sometime for the > application to start. (This is the step of creating configuration and > session factory I'm talking about, typically written in application start). > You can make it less harmful by caching the configuration (mapping, etc) > and loading from a cache file. There was another thread in the list talking > about that. This will save you a lot eveyr time you load from the cache, yet > when the configuration changes and the configuration needs to be built not > got from cache, it'll still take sometime. > (Yes, this is an issue also for Entity Framework, and not an issue for > LLBLGen ORM as it doesn't load this in runtime but generates it) > > During application tasks like read and save etc, number of tables should > not count I think. > > > Regarding LINQ provider. It's fine I guess. I'm one of those using it in > production. Not everything is supported, but not worse than Entity Framework > LINQ provider itself I guess. You'll not find a 100% LINQ hero even from > Microsoft itself if you ask me. > > -- > *Mohamed Meligy* > Senior Developer, Microsoft Technologies - Technical Delivery Group > Injazat Data Systems > P.O. Box: 8230, Abu Dhabi, U.A.E. (*GMT+4*)** > > Direct: +971 2 4045385 > Mobile: +971 50 2623624, +971 55 2017 621 > Email: [email protected] > Weblog: *http://gurustop.net* > > > > On Wed, Jul 14, 2010 at 5:23 AM, Diego Mijelshon > <[email protected]>wrote: > >> What is your question 1? What are your concerns? (I see no question marks >> there...) >> >> And 2... yes, the LINQ provider is working well, which doesn't mean it's >> perfect. >> I'm not a NH committer, but I'd recommend it without hesitation. >> >> Diego >> >> >> >> On Tue, Jul 13, 2010 at 18:00, Max André Bündchen >> <[email protected]>wrote: >> >>> That's my first post at nhusers! I found many older post about some of >>> my subjects but I can't get a conclusion by myself. The questions is >>> general, not detailed, but I hope I can get some tips from the >>> experienced users about a direction. >>> >>> My team is migrating a large project to .Net (large means we have >>> about 400 tables in the database splited in 12 integrated modules) and >>> we would like to use NHibernate + Linq (that's the reason to use the >>> trunk version) to manage data access instead of direct access and T- >>> SQL (the current not-.Net version works with T-SQL). >>> >>> My questions are about: >>> >>> 1. Performance in cases with huge meta-data/tables (I know, it depends >>> a lot of other things). >>> 2. There's many post in the group talking about the successful use of >>> the new Linq provider in production environments, but is it >>> recommended by the developers? The 2k+ unit tests used to verify the >>> trunk say yes. :) >>> >>> Sorry for some mistakes, but English is my third language. :( >>> >>> -- >>> 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]<nhusers%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/nhusers?hl=en. >>> >>> >> -- >> 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]<nhusers%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> > > -- > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- 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.
