hi Frederic, what do you mean by code generation from the database? btw, Datasets is out of the question :) Datasets is something for people who are used to work with framework 1.1 in my eyes :) everything will stay object oriented because it's just very clear what the code is really doing and what data you are using for it. I wouldn't suggest using Datasets in any case.
using lazy loading is a different way of programming I think, but in my eyes it's still much more effective to keep lazy loading in mind while programming. Entity framework is still out of the question (but that will change in .Net 4.0, since they will support the use of Services and POCO with EF) If you really want to keep the complete relational mapping the way it should be with NHibernate, it's almost impossible to disable lazy loading at that point because you could have category entities which would be loaded with all stuff that is organized within that category. that would be completely obsolete when you want to edit the category itself. if you are an architect, you probably have seen quite allot of techniques to load data, and I bet not a single one of them is as easy as NH or EF to use :) development speed is growing at percentages that you can't imagine, and especially when you have to maintain an application. That's why we chose for NHibernate and WCF because EF is still just in it's beginning process. however I expect allot of improvements in 4.0 Our dataAccessLayer will also be only used within local network, so we don't need to worry about security or other controls that won't have the capability of lazy loading. So keeping the above in consideration, in my opinion, the lazy loading is a very good idea when your developers know how to use the lazy loaded relations, no? and last of all, what is NHibernate Sharding? my mother language isn't English so I don't really know the meaning of it. And do you possibly have some more information about it? articles? blogs? On 9 feb, 09:45, Frederic <[email protected]> wrote: > Le 09/02/2010 09:29, Peter Derwa a crit : > > > @Jos , do you also have some documentation about the lazy loading > > project? > > It looks very very good! but of course it would be much easier if i > > had something to read, now i really have to search what all is for. > > there are no comments, too bad.. > > > On 8 feb, 12:21, Peter Derwa<[email protected]> wrote: > > >> hmmm what are the disadvantages? > >> My current position is that i'm only seeing an improvement in my speed > >> when i could use this. > >> now i'm using lazy = false on every single thing so you can imagine > >> the load.. > > >> On 5 feb, 06:59, Rhys C<[email protected]> wrote: > > >>> This is an aweful idea. > >>> you will find out why in.... i guess 2-3 months > > >>> Please dont distribute your NH objects, yeah its sounds like a cool > >>> thing to do, but its not. > > >>> On Feb 3, 3:13 pm, Peter Derwa<[email protected]> wrote: > > >>>> Hi Allan, I don't want to remove the lazy loading, i want to overwrite > >>>> it with a service call to do the lazy loading! > > >>>> grt > > >>>> On 2 feb, 14:58, "[email protected]"<[email protected]> > >>>> wrote: > > >>>>> What you need is a data contract serializer to push data across the > >>>>> pipe (the example below is only for outgoing). If it see's an > >>>>> uninitialized proxy, it will skip serialization on it. > > >>>>> using System; > >>>>> using System.CodeDom; > >>>>> using System.Reflection; > >>>>> using System.Runtime.Serialization; > >>>>> using System.Collections.ObjectModel; > >>>>> using log4net; > >>>>> using NHibernate.Proxy; > > >>>>> namespace MyNamespace.ServiceModel { > >>>>> public class NhDataContractSurrogate : IDataContractSurrogate { > >>>>> private static readonly ILog log = LogManager.GetLogger(typeof > >>>>> (NhDataContractSurrogate)); > > >>>>> #region IDataContractSurrogate Members > >>>>> public object GetObjectToSerialize(object obj, Type > >>>>> targetType) { > >>>>> log.Debug("Checking object"); > >>>>> var proxy = obj as INHibernateProxy; > >>>>> if (proxy != null) { > >>>>> log.Debug("Hibernate proxy found"); > >>>>> var li = proxy.HibernateLazyInitializer; > >>>>> if (li.IsUninitialized) { > >>>>> log.Debug("Hibernate proxy is not initialized and > >>>>> will not be serialized"); > >>>>> obj = null; > >>>>> } > >>>>> else { > >>>>> obj = li.GetImplementation(); > >>>>> log.DebugFormat( > >>>>> "Hibernate proxy was initialized and has been > >>>>> casted to its implementation of type '{0}'", > >>>>> obj.GetType().FullName > >>>>> ); > >>>>> } > >>>>> } > >>>>> return obj; > >>>>> } > > >>>>> public object GetCustomDataToExport(Type clrType, Type > >>>>> dataContractType) { > >>>>> return null; > >>>>> } > > >>>>> public object GetCustomDataToExport(MemberInfo memberInfo, > >>>>> Type dataContractType) { > >>>>> return null; > >>>>> } > > >>>>> public Type GetDataContractType(Type type) { > >>>>> return type; > >>>>> } > > >>>>> public object GetDeserializedObject(object obj, Type > >>>>> targetType) { > >>>>> return obj; > >>>>> } > > >>>>> public void GetKnownCustomDataTypes(Collection<Type> > >>>>> customDataTypes) { > >>>>> } > > >>>>> public Type GetReferencedTypeOnImport(string typeName, string > >>>>> typeNamespace, object customData) { > >>>>> return null; > >>>>> } > > >>>>> public CodeTypeDeclaration ProcessImportedType > >>>>> (CodeTypeDeclaration typeDeclaration, CodeCompileUnit compileUnit) { > >>>>> return typeDeclaration; > >>>>> } > > >>>>> #endregion > >>>>> } > > >>>>> } > > >>>>> On Feb 2, 5:37 am, Peter Derwa<[email protected]> wrote: > > >>>>>> Hey, > > >>>>>> I've downloaded the new version of NHibernate and I found some > >>>>>> comments about the possibilities to create your own custom lazy loader > >>>>>> for the new NHibernate version. > >>>>>> Now that looks great!!! we are using a WCF Service so we are currently > >>>>>> working with lazy = false, and that kinda sucks big time, because when > >>>>>> loading a complete table with lots of relations, that will consume > >>>>>> quite allot of time. > > >>>>>> Could someone point me into a right direction of how to do that? I was > >>>>>> not able to find the right article yet. > >>>>>> One note to keep in mind, we have multiple projects aka databases, so > >>>>>> in my lazy loading customization i'll have to be able to add that > >>>>>> project ID to create a session to the right database! > > >>>>>> grt > > Sorry for the late reply but I'm running with both WCF and Nhibernate > > Sad to say,but enabling lazy loading because your entities are too big > is a mistake. > This (common) error is just the result of code generation from the > database, and especially if you need to think in terms of SOA is a bad idea > > As an architect, my point is that there no way I never know the exact > size of an object graph that will be send accros boundaries and that the > "business responsabilities" are defined at persistence level. > If you need to have a1:1 vision of your database, well in a distributed > scenarios, Dataset is what you're looking for, nh is useless and risky, > or use SQLServer to expose SP as services. > > Generally speaking, when you generate code directly from the Database, > the generated code is more or less stupid : > It does not knowthe business role of the object, it does not make the > difference between two relation ships if they technically are the same. > > If you use Lazy loading (I mean if you ever suceed), this is going to be > a terrible mess as well as a timebomb. > WCF Sessions,Nhib Sessions, timeout, serialisation, and that's only for > reading, still needs to work on updates, saves, caching... > > If you reallocate your time using NH to get readonly objects, use 2Nd > level cache for "informative objects, a.k.a start from an object, you > will then get a clear and objective visionof your persistence issues. > > Then for your several db pb,you will confidently take a look at > Nhibernate Sharding. > > Good luck, > > Fred -- 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.
