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.
