If NHibernate does not have a designer, what is this http://www.slyce.com/ ?
On Wed, Jul 14, 2010 at 3: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. > -- Fabio Maulo -- 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.
