How to reinforce types without composition/inheritance

[Guest]

The answer might be obvious, but I'm looking for inout on the following
scenario.

I have a class called Employee that looks like this:

Public Class Employee
Private _employeeId As Int16
Public Property Id As Int16
Get
blah, blah......

This class is mapped to an Employees table and empId maps to the table's
primary key.

I have another class called Attendance. It maps to a table called
Attendence, which has a foreign key (employeeId) to the Employees table.

In the Attendance class, I want to store the employeeId value I retrieved
from the Attendance table. Because the value is a simple one, I don't want to
instantiate a new Employee object for each Attendance object. However, I do
want to reinforce the same type in both classes.

The idea is to prevent coding incorrect types. If I were doing something
like this in SQL Server, I would consider a UDT. I'm looking for a similar
technique in .Net.

Would a Structure somehow fill this requirement? Is there some better
practice? Should I simply maintain a data dictionary somewhere and tape it to
the wall? I welcome your thoughts.

Barry

 

[Oliver Sturm]

Hello Barry,

If you ask me, you should have a property of type Employee on your
Attendance class - it seems a very bad practice to fiddle with the record
IDs from outside your objects. Of course you could easily code that
property in such a way that it would only fetch the Employee data if it
was actually accessed, thereby eliminating any overhead the composition
approach might have.

My real advice is to go and find a 3rd party ORM package... there's an
awful lot of theory and practical work that has been researched and done
by several vendors, so why do it all yourself again. I recommend XPO by
Developer Express (www.devexpress.com/xpo), but don't trust me, I work for
them...


Oliver Sturm

 

[Guest]

Oliver,

Thanks for your reply.
I've drawn the same conclusion. However, I am still confused about one thing.

Let's say I store and employee object as a property of the attendance
object. When I fill the attendance object from the database, I can also join
to the employees table to retrieve other pertinent employee properties, like
last name and first name. This allows me to display these in a UI using:
objAttendance.Employee.FirstName

Now the UI allows the user to select a different employee for that record
using a combobox. I can update the objAttendance.Employee.Id from the
selected value, but I also want to update objAttendance.Employee.FirstName
and objAttendance.Employee.LastName. A cheesy solution would be to grab the
value from the combobox, but it seems to make more sense to have the employee
class set these values when it's Id property changes.

Is this the correct approach?

Thanks for the suggestion about ORM tools. We're currently using CSLA, which
wraps a lot of the class-to-db interaction.

Barry

 

[Oliver Sturm]

Hello Barry,

Now the UI allows the user to select a different employee for that record
using a combobox. I can update the objAttendance.Employee.Id from the
selected value, but I also want to update objAttendance.Employee.FirstName
and objAttendance.Employee.LastName. A cheesy solution would be to grab the
value from the combobox, but it seems to make more sense to have the
employee
class set these values when it's Id property changes.

It's simple, really - for each Employee record that has been loaded from
the database there would be exactly one instance of the Employee class
created in memory (of course assuming your Employee data is all in one
table - this is not the topic here). The "exactly" is important, see
Martin Fowler on Identity Maps for this. In any case, if the Employee that
is assigned to an Attendance object is changed, that means the setter on
the Employee property is called (and an Employee object passed in,
obviously). The class would then store the ID of the newly assigned
Employee in the background, as well as keeping the reference to the
Employee instance.

Note the order in which things work - after these steps, of course the
reference to "objAttendance.Employee.LastName" would display the correct
value - what else would it display? It doesn't have any memory of what was
there before, unless you explicitly implement something like that.

Thanks for the suggestion about ORM tools. We're currently using CSLA,
which
wraps a lot of the class-to-db interaction.

Yeah, well... I don't want to get into discussions over this, so let me
put it like this: my personal opinion of CSLA is that while it has some
interesting higher-level functionality, it's a long way from what a good
ORM tool should be.


Oliver Sturm

 

[Guest]

It's simple, really - for each Employee record that has been loaded from
the database there would be exactly one instance of the Employee class
created in memory (of course assuming your Employee data is all in one
table - this is not the topic here). The "exactly" is important, see
Martin Fowler on Identity Maps for this. In any case, if the Employee that
is assigned to an Attendance object is changed, that means the setter on
the Employee property is called (and an Employee object passed in,
obviously). The class would then store the ID of the newly assigned
Employee in the background, as well as keeping the reference to the
Employee instance.

I see what you're saying. My comboboxes are typically based on a simple
name/value type so other properties are not usually available. However, if I
load it from a more robust collection, I have access to all properties. When
I make a selection from the combobox, I set the attendance object's employee
property from the the employee collection. This make a lot of sense to me.

Yeah, well... I don't want to get into discussions over this, so let me
put it like this: my personal opinion of CSLA is that while it has some
interesting higher-level functionality, it's a long way from what a good
ORM tool should be.

I didn't mean to suggest that CSLA was an ORM tool, just that I think it
would stand in the way of using such a tool. The good news is that my
projects are usually fairly simple.

Thanks again for your replies.

Barry

 

[Oliver Sturm]

Hello Barry,

I see what you're saying. My comboboxes are typically based on a simple
name/value type so other properties are not usually available. However, if
I
load it from a more robust collection, I have access to all properties.
When
I make a selection from the combobox, I set the attendance object's
employee
property from the the employee collection. This make a lot of sense to me.

Right. Assuming you are working with collections of objects anyway, why
not just bind one of them to the combo box? No reason to extract a subset
of information only for the purpose...

I didn't mean to suggest that CSLA was an ORM tool, just that I think it
would stand in the way of using such a tool.

Not necessarily. I know that some of our customers (people who use our ORM
tool, XPO) have made it work in conjunction with CSLA.


Oliver Sturm