Thanks,

Brian

public Class1(IEcoServiceProvider serviceProvider) : base(serviceProvider){try

{

// Place user code ONLY here

Class2 class2 = new Class2( serviceProvider );

class2.Class1 = this;

}

catch (System.Exception)

{

this.Deinitialize(serviceProvider);

throw;

}

}

This enures that a Class2-object is always created and linked when you create a Class1-object.

Regards

Thomas

Brian

I would strongly advise against you doing this.  When you set a property you expect side affects, when you read it you don't.  You are introducing a side affect where none would be expected.  As a consequence you would have to ensure that anywhere within your application that you read this property you deal with the created object accorindly. 

01: Start/Rollback a transaction.  This could be a pain because you might already be in a transaction within your business class logic.

02: Start/Undo an undo block.  This would be the best option, but is still a lot of work to add just to read an object.

Otherwise you'd have to do something like this in the property getter

01: Start undo block
02: Create it
03: UpdateDatabaseWithList(objects in the undo block)

This would force you to have to put the embedding in the child object and not the parent object, which isn't always desirable.

There are so many reasons you don't want to do this :-)

====
Pete

I'm not so sure I agree that putting code in a contructor that is auto generated by EM is better than having an option in the association to automatically create the object.  I don't like writing code when an option in the modeler would do it for me.  Maybe I'm just lazy.   Come to think of it, if I wasn't lazy, I'd probably wouldn't be using ECO and would be writing my own SQL and code to hydrate and dehydrate my objects.

The main reason that it is better is because it is predictable.  You know exactly when that object will get created, whereas with a lazy-create you have no idea at all when the calling program is going to instantiate it, and as a result the calling program needs to know exactly when it can or cannot read that value.  You end up not being able to evaluate simple OCL statements such as

self.someAssociation.somethingElse

without then having to update the database just in case, but you might not be able to update the database yet because the user might be making edits which are not yet valid.  You also have the problem that Scot (I think it was) mentioned, two people might create the object at the same time and update the DB.  At least within the constructor no two people can create the same object at the same time.

====
Pete

As I mentioned before I get the lazy-create problems.  What I am suggesting is having an option in EM for an association end that determines whether a new object instance is created immediately.  Basically does the same thing as putting the code in the constructor.  I really don't like adding code in the middle of generated code.  A simple option on the EM association end configuration would eliminate the need to add this code.  The option could be added to the style comboBox as "Composition - auto create".

Regards,

Brian