ObjectSpaces 2

Comments

# Steve said on January 21, 2004 10:21 AM:

I used a dirty flag in my base object to track whether or not the object has been changed. It does introduce a little bit of extra work for the developer. However, the extra SetDirty(); call in property sets isn't too big of a burden. I do like the idea of letting the framework keep track of all the properties and whether or not they've been changed but as you said I've stayed away from it because of performance. Based on some recent posts from Paul Wilson I'm wondering if its really much of an issue in the overall perf of the entire app. I've put it on my list of things to look into for future revs of our mapper.

# Frans Bouma said on January 21, 2004 10:29 AM:

It's how you track the changes, Steve :) In the situation of ObjectSpaces, if I have an own written class 'Customer' and I change the property 'CustomerID' somewhere in my code, the Objectspace object has to know that I did that. This means that it has to track changes somehow but because I wrote the whole class, it's not possible to add an event handler somewhere :) This thus opens up some problems: keep an old copy around or inject code in the runtime byte stream?

# Paul Gielens said on January 21, 2004 10:47 AM:

ObjectSpaces tracks changes by implementing the IObjectNotification interface... by hooking event handlers that is.

http://longhorn.msdn.microsoft.com/lhsdk/ref/ns/system.data.objectspaces/i/iobjectnotification/iobjectnotification.aspx

# Maxim V. Karpov said on January 21, 2004 12:16 PM:

Dino,
I personally think that adoption of ORM mappers are still slow and not a mainstream because every ORM is implemented based on its own Framework, so before you can be productive you need to learn framework first and then start coding.

For example, Datasets objects are still not used correctly by most developers. Why?
Answer is very simple, all of the codes and samples you find do not talk about what are the problems can be solved with Datasets rather they are just code-snippets here and there.

What would be cool is to have an article about what does it take to write a ORM application. Presistance and ext....

My two cents, Maxim

# Scott said on January 21, 2004 12:44 PM:

Maxim,

Ditto++

Do a search for "Databinding ASP.NET', almost every page returned will how you databinding a DataSet to a DataGrid. It's the same with ObjectSpaces, do a search ObjectSpaces and you'll find a ton of snippets mapping "Orders" to "Customers".

# Frans Bouma said on January 21, 2004 02:46 PM:

IObjectNotification is the other way around. I'm talking about my Customer class, I tell objectspaces to track changes and I change its property CustomerID, then I call persistchanges and objectspaces can figure out that CustomerID has changed and should be changed in the database.

That's hard to do if you work with non-intrusive classes.

# Apolon Ivankovic said on January 21, 2004 08:28 PM:

A lot of the functionality I would like to see in ObjectSpaces would require some changes in compiler functionality. It would be great if:

a) There was syntactic sugar for injecting common code into Properties.
i.e. without IL post processing.

public property string Name(name);

would actually be treated as something like:

private string name;
public string Name
{
get { return GetProperty( propertyof(Name), ref name ); }
set { SetProperty( propertyof(Name), ref name, value ); }
}

where GetProperty/SetProperty are methods of an interface that objects can implement. The GetProperty/SetProperty base class implementations would then be able inform ObjectSpaces whenever a get or set on a persistable object occurs. The ref parameters allow the private fields to be get/set as needed by the ORM layer.

This sort of functionality would also be useful for applications other than an ORM layer.


b) Properties could be referred to in code in a typesafe manner.
e.g. typeof(Person) refers to the Reflection Type instance for person.
propertyof(Name) or propertyof(Person.Name) could refer to the Name property descriptor of the Person object.

I would far prefer to hard code a referance to propertyof(Name) to refer a property rather than refer to it using a string "Name". The compiler could then be used to be identify code faults rather than at runtime if the string approach is used.


c) Application Base class
Having a fixed base class for ObjectSpace applications would be a bit of a pain. Allowing applications to have their own base classes as long as certain ObjectSpaces interfaces are implemented would be a good compromise. The application base class could then contain some helper objects which make it easy to implement the required interfaces i.e. extension by containment rather than inheritance from a fixed base class.


The sort of functionality presented in (a) through (c) would allow ObjectSpaces to get into the guts of application objects without putting too much of a burden on the application programmer. In theory, the approach should result in better performance because there is less need for look ups and state comparison to process the persistable changes. The functionality would also be useful in "plumbing" type functionality not related to ORM/ObjectSpaces.

# Ryan Heath said on January 27, 2004 07:03 AM:

Frans,

Just a wild guess;

Serialize the object being tracked into a temp. location.
Then on persisting serialize the object again, and
compare the binaries with the previous serialized data.

Dont know how it will perform, but it is very transparent.

Leave a Comment

Title (required) 

Name (required) 

Your URL (optional)

Comments (required) 

Remember Me?