COM architecture advice sought
| Author |
Message |
|
Neil Kise
#1 / 8
|
 COM architecture advice sought Hi, I am currently scoping the architecture for my COM objects and have a
question. First of all I should say that all my COM objects are
stateless. In the past, due to the stateless nature of my objects, I
have created objects such that the name of the object simply indicated
a grouping of methods. If I have a 'User' object then it would
support methods not only for a single user, but also multiple users.
For example, the 'User' object would have methods for 'Insert',
'Delete', and 'Update', but it would also have methods such as
'ListAll', 'ListByActiveStatus', etc.
As I have begun to design my new architecture, I have tried to design
the COM objects as if I were creating stateful objects. I am not
creating stateful objects, but believe that perhaps it would be best
to do so, as I have no idea what the future may hold (i.e. perhaps
some of them become stateful). But that leads me to my question.
Where does a method such as 'ListAll' (Users) go in a stateful design?
I wouldn't expect it to go on the User object, as an instance of the
User object represents a single actual user.
My apologies, but all of my COM development has been stateless and I
have never given this sort of thing a second thought. I feel that
perhaps I am missing something obvious.
Thank you for your time,
-Neil
|
| Sat, 24 Jan 2004 09:02:43 GMT |
|
 |
|
Charles McDonal
#2 / 8
|
COM architecture advice sought Neil I cannot really help you but I will give you my thoughts on the subject.
I have a little experiance in creating statefull objects, and for each
class I would define 2. A parent class definition, say clsUsers and a
child class definition, say clsUser. These are not parent / child
objects in the real sence, but the 'parent' in this case would do
operations which deal with multiple 'children'. It is in effect a type
of container object with Item(index) and Count methods etc. So clsUsers
would have a Load(param) method which would do a fetch to retrieve all
users satisfying the parameter, and create a clsUser object for each
record returned. These objects would then be contained in a private
collection object within clsUsers. I think you may be getting my drift
here. Good books on statefull objects are Visual Basic 6 Business
Objects, and VB6 Distributed Objects. Both by Rockford Lhotka.
I on the other hand am now moving into the stateless side of things, and
am unsure how to deal with everything. For example, a security structure
consisting of 4 tables (Roles, Privileges, RolePrivileges and UserRole)
should one class definition be defined to deal with all these tables, or
should I create a number of class definitions. All these will be running
on an application server inside COM+. Is there any benifit in creating
multiple class definitions?
Cheers
Charles
Quote:
> Hi,
> I am currently scoping the architecture for my COM objects and have a
> question. First of all I should say that all my COM objects are
> stateless. In the past, due to the stateless nature of my objects, I
> have created objects such that the name of the object simply indicated
> a grouping of methods. If I have a 'User' object then it would
> support methods not only for a single user, but also multiple users.
> For example, the 'User' object would have methods for 'Insert',
> 'Delete', and 'Update', but it would also have methods such as
> 'ListAll', 'ListByActiveStatus', etc.
> As I have begun to design my new architecture, I have tried to design
> the COM objects as if I were creating stateful objects. I am not
> creating stateful objects, but believe that perhaps it would be best
> to do so, as I have no idea what the future may hold (i.e. perhaps
> some of them become stateful). But that leads me to my question.
> Where does a method such as 'ListAll' (Users) go in a stateful design?
> I wouldn't expect it to go on the User object, as an instance of the
> User object represents a single actual user.
> My apologies, but all of my COM development has been stateless and I
> have never given this sort of thing a second thought. I feel that
> perhaps I am missing something obvious.
> Thank you for your time,
> -Neil
|
| Sat, 24 Jan 2004 18:16:11 GMT |
|
|
|
Gan
#3 / 8
|
COM architecture advice sought I think a Users collection object and some User objects are better idea
|
| Sun, 25 Jan 2004 15:25:04 GMT |
|
|
|
David Blane
#4 / 8
|
COM architecture advice sought Charles (or anybody else), I have read your reply and think that you might be able to help me with a
com architectural question of my own.
I am trying to design an application at the moment which has a structure
something similar to the one you mentioned with the clsUsers and clsUser
classes.
For the example, I have two classes, Accounts and Account. I also have a
data access layer. When I want to create the Account objects, the Accounts
object uses an object in the data access layer to return a recordset
containing records from an Accounts table in the database and then it
creates the Account objects from the data in it. Confused yet? The Accounts
object is really just a wrapper for a private collection of Account objects.
This means I can have Add and Remove methods on the Accounts object and it
will update the private collection and keep the recordset in sync.
The problem arises when I update properties on the Account objects. I want
the Account object to automatically update the values in the database when
it's properties are changed but because the Accounts object is the one with
the recordset I can't.
I would really appreciate any help you may be able to give me on how this
kind of thing is usually done?
Thanks in Advance,
David Blaney.
Quote: > Neil > I cannot really help you but I will give you my thoughts on the subject.
> I have a little experiance in creating statefull objects, and for each
> class I would define 2. A parent class definition, say clsUsers and a
> child class definition, say clsUser. These are not parent / child
> objects in the real sence, but the 'parent' in this case would do
> operations which deal with multiple 'children'. It is in effect a type
> of container object with Item(index) and Count methods etc. So clsUsers
> would have a Load(param) method which would do a fetch to retrieve all
> users satisfying the parameter, and create a clsUser object for each
> record returned. These objects would then be contained in a private
> collection object within clsUsers. I think you may be getting my drift
> here. Good books on statefull objects are Visual Basic 6 Business
> Objects, and VB6 Distributed Objects. Both by Rockford Lhotka.
> I on the other hand am now moving into the stateless side of things, and
> am unsure how to deal with everything. For example, a security structure
> consisting of 4 tables (Roles, Privileges, RolePrivileges and UserRole)
> should one class definition be defined to deal with all these tables, or
> should I create a number of class definitions. All these will be running
> on an application server inside COM+. Is there any benifit in creating
> multiple class definitions?
> Cheers
> Charles
> > Hi,
> > I am currently scoping the architecture for my COM objects and have a
> > question. First of all I should say that all my COM objects are
> > stateless. In the past, due to the stateless nature of my objects, I
> > have created objects such that the name of the object simply indicated
> > a grouping of methods. If I have a 'User' object then it would
> > support methods not only for a single user, but also multiple users.
> > For example, the 'User' object would have methods for 'Insert',
> > 'Delete', and 'Update', but it would also have methods such as
> > 'ListAll', 'ListByActiveStatus', etc.
> > As I have begun to design my new architecture, I have tried to design
> > the COM objects as if I were creating stateful objects. I am not
> > creating stateful objects, but believe that perhaps it would be best
> > to do so, as I have no idea what the future may hold (i.e. perhaps
> > some of them become stateful). But that leads me to my question.
> > Where does a method such as 'ListAll' (Users) go in a stateful design?
> > I wouldn't expect it to go on the User object, as an instance of the
> > User object represents a single actual user.
> > My apologies, but all of my COM development has been stateless and I
> > have never given this sort of thing a second thought. I feel that
> > perhaps I am missing something obvious.
> > Thank you for your time,
> > -Neil
|
| Wed, 28 Jan 2004 05:08:48 GMT |
|
|
|
David Blane
#5 / 8
|
COM architecture advice sought Charles (or anybody else), I have read your reply and think that you might be able to help me with a
com architectural question of my own.
I am trying to design an application at the moment which has a structure
something similar to the one you mentioned with the clsUsers and clsUser
classes.
For the example, I have two classes, Accounts and Account. I also have a
data access layer. When I want to create the Account objects, the Accounts
object uses an object in the data access layer to return a recordset
containing records from an Accounts table in the database and then it
creates the Account objects from the data in it. Confused yet? The Accounts
object is really just a wrapper for a private collection of Account objects.
This means I can have Add and Remove methods on the Accounts object and it
will update the private collection and keep the recordset in sync.
The problem arises when I update properties on the Account objects. I want
the Account object to automatically update the values in the database when
it's properties are changed but because the Accounts object is the one with
the recordset I can't.
I would really appreciate any help you may be able to give me on how this
kind of thing is usually done?
Thanks in Advance,
David Blaney.
Quote: > Neil > I cannot really help you but I will give you my thoughts on the subject.
> I have a little experiance in creating statefull objects, and for each
> class I would define 2. A parent class definition, say clsUsers and a
> child class definition, say clsUser. These are not parent / child
> objects in the real sence, but the 'parent' in this case would do
> operations which deal with multiple 'children'. It is in effect a type
> of container object with Item(index) and Count methods etc. So clsUsers
> would have a Load(param) method which would do a fetch to retrieve all
> users satisfying the parameter, and create a clsUser object for each
> record returned. These objects would then be contained in a private
> collection object within clsUsers. I think you may be getting my drift
> here. Good books on statefull objects are Visual Basic 6 Business
> Objects, and VB6 Distributed Objects. Both by Rockford Lhotka.
> I on the other hand am now moving into the stateless side of things, and
> am unsure how to deal with everything. For example, a security structure
> consisting of 4 tables (Roles, Privileges, RolePrivileges and UserRole)
> should one class definition be defined to deal with all these tables, or
> should I create a number of class definitions. All these will be running
> on an application server inside COM+. Is there any benifit in creating
> multiple class definitions?
> Cheers
> Charles
> > Hi,
> > I am currently scoping the architecture for my COM objects and have a
> > question. First of all I should say that all my COM objects are
> > stateless. In the past, due to the stateless nature of my objects, I
> > have created objects such that the name of the object simply indicated
> > a grouping of methods. If I have a 'User' object then it would
> > support methods not only for a single user, but also multiple users.
> > For example, the 'User' object would have methods for 'Insert',
> > 'Delete', and 'Update', but it would also have methods such as
> > 'ListAll', 'ListByActiveStatus', etc.
> > As I have begun to design my new architecture, I have tried to design
> > the COM objects as if I were creating stateful objects. I am not
> > creating stateful objects, but believe that perhaps it would be best
> > to do so, as I have no idea what the future may hold (i.e. perhaps
> > some of them become stateful). But that leads me to my question.
> > Where does a method such as 'ListAll' (Users) go in a stateful design?
> > I wouldn't expect it to go on the User object, as an instance of the
> > User object represents a single actual user.
> > My apologies, but all of my COM development has been stateless and I
> > have never given this sort of thing a second thought. I feel that
> > perhaps I am missing something obvious.
> > Thank you for your time,
> > -Neil
|
| Wed, 28 Jan 2004 05:08:48 GMT |
|
|
|
Gan
#6 / 8
|
COM architecture advice sought I think you should put the update method in Accounts collection, and keep
the old value of each fields in the Account object. In the Update method,
compare the value of each field with the old value and update the database.
|
| Fri, 30 Jan 2004 10:40:41 GMT |
|
|
|
David Blane
#7 / 8
|
COM architecture advice sought Thanks Gang, I can see how this would work but I've got 2 issues with it:
1. If the collection contains alot of Account objects, the overhead to
iterate through all of them, comparing old values with new values in order
to determine if the database should be updated would be too great.
2. Because of the overhead I mentioned above, you would not want to call
this method every time an Account object was updated but rather at
intervals, when there were likely to be quite a few changes. Since the
collection's Remove and Add methods would be updating the database
instantly, I could end up with some adds and deletes that had been applied
to the database but updates that had not (in the event of a failure).
Maybe I'm looking for a solution that doesn't exist but I was hoping for a
more elegant way of doing this. After all, if you forget about the database
and just consider the objects, the Add and Remove methods should be
associated with the Accounts object since these are actions you perform on a
collection while you change properties on the individual Account objects to
update them, ie. you wouldn't usually have to call an Update method on the
collection.
Dave.
Quote: > I think you should put the update method in Accounts collection, and keep
> the old value of each fields in the Account object. In the Update method,
> compare the value of each field with the old value and update the
database.
|
| Sat, 31 Jan 2004 07:36:35 GMT |
|
|
|
Gan
#8 / 8
|
COM architecture advice sought Another way is to hold a reference to the collectiion object in the Account
object, but it is also not very elegant
|
| Sat, 31 Jan 2004 14:23:55 GMT |
|
| |
|
