is this a good abstract base class design?
Messages   Related Types
This message was discovered on ASPFriends.com 'aspngarchitecture' list.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.

Francesco Sanfilippo
I am trying to follow the Engine-Collection-Class design pattern in
building some abstract base classes for my business objects to inherit
from. I was going to use interfaces, but decided abstract classes were
more appropriate for my circumstances.

Please glance at this code if you have a minute, it's just skeleton
code with no meaningful methods defined yet. I am just trying to see
if I am heading in the right direction so far.

A question...in the CBusinessObjectCollection class, do I need to
override IList.Add(), IList.Insert(), etc. methods? Also, is InnerList
the main storage unit inside the CollectionBase class?

Comments appreciated!
Thanks in advance,
Francesco

http://66.27.51.62/pr2002/baseclasses.html

Reply to this message...
 
    
Rick Elbers (VIP)

The particular frase below doesnt seem
very clean, and not only semantically:-)

private bool _isDirty = false;
public bool isDirty
{
get { return _isDirty; }
set { _isDirty = value; }
}

private bool _isNew = false;
'more methods to return status of isNew

Remember an object has basically to prove itself
by responsibilities and encapsulation, not
by publishing..!
Rick

----- Original Message -----
From: "Francesco Sanfilippo" <Click here to reveal e-mail address>
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Tuesday, July 16, 2002 8:36 PM
Subject: [aspngarchitecture] is this a good abstract base class design?

[Original message clipped]

Reply to this message...
 
    
SHEATHER,Kristoffer
I think one of the first things you should do is drop those ugly
prefixes from your class names..

-----Original Message-----
From: Francesco Sanfilippo [mailto:Click here to reveal e-mail address]=20
Sent: Wednesday, July 17, 2002 4:36 AM
To: aspngarchitecture
Subject: [aspngarchitecture] is this a good abstract base class design?

I am trying to follow the Engine-Collection-Class design pattern in
building some abstract base classes for my business objects to inherit
from. I was going to use interfaces, but decided abstract classes were
more appropriate for my circumstances.

Please glance at this code if you have a minute, it's just skeleton code
with no meaningful methods defined yet. I am just trying to see if I am
heading in the right direction so far.

A question...in the CBusinessObjectCollection class, do I need to
override IList.Add(), IList.Insert(), etc. methods? Also, is InnerList
the main storage unit inside the CollectionBase class?

Comments appreciated!
Thanks in advance,
Francesco

http://66.27.51.62/pr2002/baseclasses.html

| [aspngarchitecture] member Click here to reveal e-mail address =3D YOUR ID

| http://www.asplists.com/asplists/aspngarchitecture.asp =3D JOIN/QUIT=20
| http://www.asplists.com/search =3D SEARCH Archives

Notice:
The information contained in this e-mail message and any attached files may
be confidential information, and may also be the subject of legal
professional privilege. If you are not the intended recipient any use,
disclosure or copying of this e-mail is unauthorised. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete all copies of this transmission together with any attachments.

Reply to this message...
 
    
Russ McClelland
Also, I would think carefully about whether or not you need all the
interface methods you have defined. In many systems, you may need to
read objects, but not save, delete or update them. Putting these
methods on the base class will force subclasses to implement the methods
even if they don't need the behavior for their application.

Regarding an "isDirty" flag of some sort. We have found another
alternative(actually two) that serves two purposes with will help with
the persistence aspects of your design. =20

First, we implement an "OID" property on each persistent object. If the
OID is 0, the stored proc decides to do an Insert. If the OID is not 0,
then it executes an update. Anything object with an OID of 0 is dirty,
but you may still need an "IsDirty" flag of some sort.

Second, each persistent object inherits a Timestamp property. When an
object graph is faulted in from the DB, each instance in the graph is
assigned a timestamp from the DB record. During an update, we compare
the timestamp to the timestamp in the record. If they are the same, we
know that no one else has modified the record since we read the values,
so its safe to do the Update. From there you can either throw an error
or make the SP/code smart enough to look at each field and decide if the
two edits affected the same field. If not, save only the changed
fields, etc. We usually just throw an error, re-read and force the user
to make their changes again.

We usually don't try to decide whether the user has changed the object
by using a dirty flag. We allow the user to to change the values and
then enable an OK button on the change. If they don't change values,
only the Cancel button is enabled. In the code for the OK button, we
always perform a save of the object. While there are some situations
where a user can "trick" the app into saving an object that hasn't
really changed, most users wouldn't go through the trouble.

Of course, this strategy may not make sense in all applications or all
scenarios. Just my two cents...

-----Original Message-----
From: SHEATHER,Kristoffer [mailto:Click here to reveal e-mail address]=20
Sent: Wednesday, July 17, 2002 6:26 PM
To: aspngarchitecture
Subject: [aspngarchitecture] RE: is this a good abstract base class
design?

I think one of the first things you should do is drop those ugly
prefixes from your class names..

-----Original Message-----
From: Francesco Sanfilippo [mailto:Click here to reveal e-mail address]=20
Sent: Wednesday, July 17, 2002 4:36 AM
To: aspngarchitecture
Subject: [aspngarchitecture] is this a good abstract base class design?

I am trying to follow the Engine-Collection-Class design pattern in
building some abstract base classes for my business objects to inherit
from. I was going to use interfaces, but decided abstract classes were
more appropriate for my circumstances.

Please glance at this code if you have a minute, it's just skeleton code
with no meaningful methods defined yet. I am just trying to see if I am
heading in the right direction so far.

A question...in the CBusinessObjectCollection class, do I need to
override IList.Add(), IList.Insert(), etc. methods? Also, is InnerList
the main storage unit inside the CollectionBase class?

Comments appreciated!
Thanks in advance,
Francesco

http://66.27.51.62/pr2002/baseclasses.html

| [aspngarchitecture] member Click here to reveal e-mail address =3D YOUR =
ID

| http://www.asplists.com/asplists/aspngarchitecture.asp =3D JOIN/QUIT
| http://www.asplists.com/search =3D SEARCH Archives

Notice:
The information contained in this e-mail message and any attached files
may
be confidential information, and may also be the subject of legal
professional privilege. If you are not the intended recipient any use,
disclosure or copying of this e-mail is unauthorised. If you have
received
this e-mail in error, please notify the sender immediately by reply
e-mail
and delete all copies of this transmission together with any
attachments.

| [aspngarchitecture] member Click here to reveal e-mail address =3D YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp =3D JOIN/QUIT
| http://www.asplists.com/search =3D SEARCH Archives

Reply to this message...
 
 
System.Collections.CollectionBase
System.Collections.IList




Ad
MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT
 
 Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com