A general question about objects

Grimolfr

The reference will still be there, but it will be broken. The reference is actually in IntPtr (pointer), which is really just a memory address. The only way the reference won't break is if object B happens to end up at the same memory address on the server (unlikely), or if you manually tear down the A object on one end, send the data, and manually reconstitute the A object on the other end, thus fixing the pointers. Now, if A and B are both serializable, and you implement ISerializable in such a way as to serialize/deserialize B as a part of A, then it would be fairly simple to ensure that things are torn down and rebuilt properly.

Grim

(aka Toby)

MCDBA, MCSD, MCP+SB

Need a Second Life?

Christer Claesson

Thank you for the reply, the reason I did not try it is that it is someone in my group that is coding that part and we are doing some "theoretical" coding now and needs to make some design choises. It turns out that he is using Java and will bind his server with our j# interface, I think that would work as he is not using anything after 1.1 I think.(We will later throw everything in a project in VS.NET) The thing is that we have alot of references between objects and is wondering about the solution(I've asked something similar before). We tried to go away from our database thinking and have it like this: Employee has a collection of resources. Resources has one reference to an employee and one to a Project. Project has a collection of resources. This is that we want a client/server solution and how would you solve this problem in "real" life. We can do a simple program without any server or database but we want to make it as real as possible else it feels like we wont learn much. Before we just had "foreign keys" (project id, employee id) in the resource, but I dont think that is good object oriented coding? But it makes it much easier to send objects to and from a server as we dont need a reference between the objects..but this is bad right? Thank you for you help (And what does Microsoft MVP stand for?, you seem to know alot about .NET) :)

Heath Stewart

Grimolfr wrote: The reference is actually in IntPtr (pointer), which is really just a memory address. :wtf: Like .NET runtime serialization, the ObjectOutputStream and ObjectIntputStream hook-up the references again. Depending on how the data is formatted to be send across the wire, this has nothing to do with memory addresses. This is no different than what happens with .NET Remoting.

Microsoft MVP, Visual C# My Articles

Heath Stewart

They're called business objects and it's a good idea to have. Not only does it abstract away the data tier but provides a better programming model. "Microsoft MVP" stands for "Microsoft Most Valuable Professional". See http://mvp.support.microsoft.com/default.aspx?scid=fh;EN-US;mvpintro[^] for more information.

Microsoft MVP, Visual C# My Articles

Christer Claesson

Ok thanks, we will try to keep them even though we are having annoying problems with instanceof right now, that is on the level we are ;). But will take your advice and start trying to send objects back and forth from the server/client.

Grimolfr

I shoulda known to stay out of it as soon as I saw J#. And serialization [i]will[/i] serialize reference pointers instead of the objects they point to in some situations unless you explicitly override the serialization methods.

Grim

(aka Toby)

MCDBA, MCSD, MCP+SB

Need a Second Life?[^]

Christer Claesson

Is it possible to have a J# client and a Java server and send objects between them? As it seems now our J# client only seems to handle all objects it gets from the Java server as Strings. Just wondering if we must throw in the Server in the .NET environment or if we have made some other mistake.

Heath Stewart

I'd be interested to know what situations those are. We've used both SOAP and binary formatting (runtime serialization) in our massive N-tier application I primarily architected and objects to which member fields reference (and what not) are serialized. This is especially true for SOAP where even a byte offset for a child object isn't possible. In any case, the J# libraries work differently from the .NET FCL and to be honest, I'm really not sure about all that. It's basically a port of the JRE. I answered a question not long ago about java.util.Date. Someone for some reason thought that you could simply cast a DateTime to a Date. Not only wasn't that possible, but they use different epochs (which I remember from Java years and because of a couple recent projects interop'ing Java and .NET at the presentation layer that I developed a couple years ago).

Microsoft MVP, Visual C# My Articles

Grimolfr

I've never run into it personally, but I read a forum message (on gotdotnet.com, IIRC) where a guy was serializing an object with SerializableAttribute, and not implementing ISerializable or providing a serialization constructor. Problem was, the default serialization mechanism would serialize the function pointers assigned to any events. When he deserialized, the pointers were invalid, and caused all sorts of problems. His actual issue in the post was that the NonSerializableAttribute applies to fields only, and not to events. This was awhile ago, though. The default serialization functionality may have changed in 1.1 to not serialize event function pointers.

Grim

(aka Toby)

MCDBA, MCSD, MCP+SB

Need a Second Life?[^]

Heath Stewart

I see. That would make sense regarding delegates (event handlers). For fields, however, this shouldn't be a problem.

Microsoft MVP, Visual C# My Articles