Associative entities on CslaGen?

[Tiago Freitas Leal]

Hi all,

Do you remember the issue on PTracker about Resources (working people)
and Projects? It is solved using associative entities.
More on http://en.wikipedia.org/wiki/Associative_Entities

Of course CslaGen can handle this scenario using some black magic and
a hand made (What? You mean not generated!?) static class just like
Rocky did.

How about CslaGen taking care of it all for you?

[pandelis]

So far this problem was handled with the creation of an intermediary
table that holds the information that transforms the relationship from
many to many. Should this problem be handled programmatically,
wouldn't it need another table to make it happen as well? I mean to
store the table keys. So instead of us creating this table, you mean
the table to be generated and then an associative entity to be modeled
and generated as well.

Support for many to many relationships would be cool, but wouldnt you
rather handle that complexity on a database level yourself? i mean i
usually add some extra fields apart from keys on that table. Or some
extra foreign keys for that matter.

[Tiago Freitas Leal]

I mean having CslaGen generating code the exact same way Rocky solved
the question in PTracker. We make the tables (as we do now) and
specify a name for Associative Entity; CslaGen generates the static
class and the Insert / Update methods necessary. So it's the same
solution but you don't have to type the code.

[Andrés Villanueva]

I considered this a long long time ago and there were several reasons not to do it. There's a good point in making such base class if you're hand coding everything, but considering we're using code generation, the bulk of the common code -mostly properties and data access- is a snap to generate and has no extra cost. Rocky said himself once that there was little value in making such class if  you're using code generation, specially if all you're trying to do is save a few lines of code, since because they are generated, they are really cheap.
A good reason for doing it would be polimorphism, but since the base classes are generic, and generics are not polimorphic, that reason goes away.
Then there's an abstraction issue. Your derived classes need to know too much about the inside of the class, since they need to make sure that the data transport of choice (a datareader in our case, or a DAL object), contains the properties that the base class needs to consume. Not only that, but the insert and update procedures that each of those use need to have parameters for those in the base class as well.
The only good reason for reuse here (and again, quoting Rocky) is business logic. In our case business rules. But if you look at the code he built in his latest samples, he uses a separate class to hold that logic, effectively making the "manual" part of the whole process a one liner: the call to AddRule().

With all those considerations in mind, if we still go ahead and build such a feature, it would be much harder to use than the current scheme. Right now, you end up building two objects that hold similar (but not all the same) properties. The process for creating that is rather simple and flexible. You can have it done in a few clicks. The other way, would involve creating a third class and making sure we use it as base to the other two.

So as you can see, I did give this some serious thought, but it was Rocky himself that inadvertedly talked me out of it. :)

Cheers!

--
http://groups.google.com/group/CslaGenerator
Post to: CslaGe...@googlegroups.com
Unsuscribe: CslaGenerato...@googlegroups.com
Join us on #CslaGenerator @ irc.freenode.net

--
Andrés

[Tiago Freitas Leal]

Hi Andrés,

On 15 Jun, 02:44, Andrés Villanueva <xal1...@gmail.com> wrote:
> With all those considerations in mind, if we still go ahead and build such a
> feature, it would be much harder to use than the current scheme. Right now,
> you end up building two objects that hold similar (but not all the same)
> properties. The process for creating that is rather simple and flexible. You
> can have it done in a few clicks. The other way, would involve creating a
> third class and making sure we use it as base to the other two.

So I thought. But then again all you need is an extra plain text
property that holds the name of the static class to be generated -
what I call the "Associative Entity Type". The templates can be smart
enough to pass to that class only the ReadWrite/CreateOnly/WriteOnly/
UpdateOnly value properties (according to Insert or Update use cases).
That part is solved. All there is toi be done is the
AssociativeEntityType class generation. I don't expected major
problems.

BTW, except for the authz, C# templates are ready for CSLA.NET 4.0.0
Lots of changes made to template helper. A few properties added here
and there. I also migrated my changes to 20090529.

[Tiago Freitas Leal]

Hi again,

On 15 Jun, 02:44, Andrés Villanueva <xal1...@gmail.com> wrote:

> The other way, would involve creating a
> third class and making sure we use it as base to the other two.

Sorry I missed that part. no base classes used. I'm using the same
solution Rocky uses on Project Tracker and that involves no base
class. Have a look at "internal static class Assignment" to see what I
mean.

[pandelis]

Tiago can you please add a link to the discussion in the csla forum
that is related to the topic?

[Tiago Freitas Leal]

Hi Pandelis

On 17 Jun, 06:16, pandelis <pandela...@yahoo.com> wrote:
> Tiago can you please add a link to the discussion in the csla forum
> that is related to the topic?

This issue is dicussed in both Rocky's books. Don't remember a
CSLA.NET forum thread about it.

[Tiago Freitas Leal]

Hi Again Andrés,

On 15 Jun, 02:44, Andrés Villanueva <xal1...@gmail.com> wrote:

> Rocky said himself once that there was little value in
> making such class if  you're using code generation, specially if all you're
> trying to do is save a few lines of code, since because they are generated,
> they are really cheap.

That's the real point: as the code is generated, there are two upsides
- it's cheap to do (you don't spend time doing it)
- no risk of making coding mistakes while repeating the same behaviour
(database access)

The point is
- currently there is no way in CslaGen to specify the second parameter
of the Update method / stored

I'll explain with a dummy (and maybe stupid) example

You have a Boys class and a Girls class. They are rather promiscuous
and each one of them may be related to many of the other.

So my Hetero table may be like this:
RelationID
BoyID
GirlID
...

and on Boys, my EditableChild GirlFriend value property collection may
be like this
RelationID
GirlID
...

and on Boys, my EditableChild BoyFriend value property collection may
be like this
RelationID
BoyID
...

In each of the EditableChild there is no need to repeat the object ID
(is pointless and bad design).

In this case, my Update methos / SP just refers to RelationID and
there is no problem at all - CslaGen can handle it (you just set
ParentInsertOnly to false)
But if my table has no RelationID, all CRUD methods / SP must have a
reference to both BoyID and GirlID
That's not a problem for Create, Insert and Delete. But for the
Update, I can set ParentInsertOnly to false but there is still no
other way to pass a second paramete:

For Boys, the parent ID is BoyID and I need to pass also the GirlID
parameter (and vice versa).

Criteria won't help as they don't apply to Updates.

Currently this is a problem/shortcomming in CslaGen. I think / need to
address the issue.

I understand I don't need to add a third class - evena static class -
in order to solve the problem. There is litle value and some
complexity added (an extra files in the project). Making a static
class raises a few (solvable) issues: the order that each object
passes the BoyID and GirlsID parameter to the static methods must be
the same (the generator must order them alphabetically)

So really what it's needed is a way to pass the "other" object ID.

[pandelis]

i had the same issues with Tiago in similar cases :)
Dealt with it the only way i could (as Adres said), but I have to
agree with Tiago. It would be nice to have that, in cases where a
child object needs to be related to 2 or more parent objects. In most
cases, these child objects are either similar or identical to each
other, in properties and behaviour.

[Tiago Freitas Leal]

Hi Andrés,

On 17 Jun, 07:59, Tiago Freitas Leal <tfreitasl...@gmail.com> wrote:

> So really what it's needed is a way to pass the "other" object ID.

The issue is solved. All I did was set the "other" Value Property
DataAccess (under Database Related) as ReadWrite (it was set to
CreateOnly).

This isn't a simple issue. In fact there are two different issues:
1) whether to pass the "other" object ID as a stored procedure
parameter - issue solved
2) whether the stored procedure uses this value for anything other
than selecting the right row - issue solved

I'm referring to the scenario where my Hetero table has a Primary Key
composed of BoyID and GirlID (and no RelationID column) - in that
case, set the Value Property DataAccess (under Database Related) to
ReadWrite.

In the alternate scenario where my Hetero table has a RelationID
Primary Key, you must set the Value Property DataAccess (under
Database Related) to CreateOnly as with aren't allowed to change the
"other" object ID after creation (unless you date twin sisters and
just can't decide each one you are dating).

My version of the templates handle both issue correctly. The thing is
I edit the templates a lot for template style, indentation and blank
lines of the generated code and some logic too. So maybe the original
version is OK, maybe it's not.