I guess Mohamed means that there is no out of the box designer. With 3rd party there is always a risk of lack of cooperation between teams (Fluent is an example) synchronization: I'm not sure either 3rd party will support NH-3 trunk before official release. correct me if I'm wrong, but Visual NH is not open-source.
Don't get me wrong: I support NH ecosystem and it is a good thing that somebody can make money by providing extra service. Just pointing out what I would consider if deciding to use 3rd party designer. Vadim. On Jul 14, 5:05 am, Fabio Maulo <[email protected]> wrote: > If NHibernate does not have a designer, what is thishttp://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.
