|
| MCC Design Pattern |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on ASPFriends.com 'aspngarchitecture' list.
| Bryan Costanich |
All,
Some time ago, in the neighborhood of 8 months ago captured a pattern that
is similar to the ECC pattern but a lot simpler and more .NET friendly while
being every bit as robust.
The pattern had a great reception and in fact was very familiar to a lot of
people, hence it being a pattern, and I got a lot of good feedback on
completing the pattern. However, I never got around to finishing it up.
I'm going to be releasing another draft of it pretty soon, but I was hoping
that I could get some feedback on it's current state.
You can find the pattern at
http://codebox.wowzer.net/code/MCC_Design_Pattern_Draft.doc
<http://codebox.wowzer.net/code/MCC_Design_Pattern_Draft.doc> .
I look forward to hearing from you on it.
thanks,
-bryan costanich
|
|
|
| |
|
| |
| |
| Deyan Petrov |
MessageHi Bryan,
I find some problems with your pattern and I am sorry to say that I wouldn't agree to use it.
First the place of the business methods/rules is not obvious. Where should I place my Business methods? In the Class, in the Collection, in the Manager or everywhere? If I place it in the class or collection, then if these are transported over the network to the client and the client tries to execute them?
Second, the responsibility of the manager is not clear enough. I think that there should be a PersistenceManager, which should deal with retrieving/updating the class and collection ONLY. There should be another entity, which should have the business methods/rules in it.
Third, the isDirty flag is not very clear. What means that an object is dirty? Is it a newly created object, modified or deleted?
I have been clearing out a .NET distributed application design during the last few weeks, I think that now I am near to clearing it out. In it the central point is that the objects have externalized state, which can be transported to the client, and there are a set of services available - like PersistenceManagers, TransactionManager, SecurityManager, ExceptionManager etc. 10x to this listserver for a recent descussion "Is this a good object desing", by the way...
Regards,
Deyan Petrov
----- Original Message -----
From: Bryan Costanich
To: aspngarchitecture
Sent: Wednesday, July 03, 2002 7:02 AM
Subject: [aspngarchitecture] MCC Design Pattern
All,
Some time ago, in the neighborhood of 8 months ago captured a pattern that is similar to the ECC pattern but a lot simpler and more .NET friendly while being every bit as robust.
The pattern had a great reception and in fact was very familiar to a lot of people, hence it being a pattern, and I got a lot of good feedback on completing the pattern. However, I never got around to finishing it up.
I'm going to be releasing another draft of it pretty soon, but I was hoping that I could get some feedback on it's current state.
You can find the pattern at http://codebox.wowzer.net/code/MCC_Design_Pattern_Draft.doc.
I look forward to hearing from you on it.
thanks,
-bryan costanich
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
|
| |
|
| |
|
| |
| Bryan Costanich |
Deyan,
I believe you've misunderstood the pattern, but that's clearly my fault in
it's presentation.
The manager's responsibility is exactly as you described PersistenceManager,
I will add a section that describes the responsibilities of the objects.
The dirty flag is the same as in the ECC design pattern. Actually these
patterns are very similar, except that much of the functionality of the
collection has been moved to the Manager so that we can have lightweight
bindable collections that are reusable.
To delete an object, let's call it user, from the datastore one would call
the UserManager.DeleteUser() method, and you might pass in an ID, or simply
the User object. You might also have a Data Accesss Layer behind that
abstracts away your datasource and so UserManager might call a
DAL.DataManager.DeleteUser() or the like.
I would write more, but I'm heading off for vacation.
Thanks for the feedback, it's clear that there is some ambiguity in the doc.
-b
-----Original Message-----
From: Deyan Petrov [mailto:Click here to reveal e-mail address]
Sent: Wednesday, July 03, 2002 9:34 AM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MCC Design Pattern
Hi Bryan,
I find some problems with your pattern and I am sorry to say that I wouldn't
agree to use it.
First the place of the business methods/rules is not obvious. Where should I
place my Business methods? In the Class, in the Collection, in the Manager
or everywhere? If I place it in the class or collection, then if these are
transported over the network to the client and the client tries to execute
them?
Second, the responsibility of the manager is not clear enough. I think that
there should be a PersistenceManager, which should deal with
retrieving/updating the class and collection ONLY. There should be another
entity, which should have the business methods/rules in it.
Third, the isDirty flag is not very clear. What means that an object is
dirty? Is it a newly created object, modified or deleted?
I have been clearing out a .NET distributed application design during the
last few weeks, I think that now I am near to clearing it out. In it the
central point is that the objects have externalized state, which can be
transported to the client, and there are a set of services available - like
PersistenceManagers, TransactionManager, SecurityManager, ExceptionManager
etc. 10x to this listserver for a recent descussion "Is this a good object
desing", by the way...
Regards,
Deyan Petrov
----- Original Message -----
From: Bryan Costanich <mailto:Click here to reveal e-mail address>
To: aspngarchitecture <mailto:Click here to reveal e-mail address>
Sent: Wednesday, July 03, 2002 7:02 AM
Subject: [aspngarchitecture] MCC Design Pattern
All,
Some time ago, in the neighborhood of 8 months ago captured a pattern that
is similar to the ECC pattern but a lot simpler and more .NET friendly while
being every bit as robust.
The pattern had a great reception and in fact was very familiar to a lot of
people, hence it being a pattern, and I got a lot of good feedback on
completing the pattern. However, I never got around to finishing it up.
I'm going to be releasing another draft of it pretty soon, but I was hoping
that I could get some feedback on it's current state.
You can find the pattern at
http://codebox.wowzer.net/code/MCC_Design_Pattern_Draft.doc
<http://codebox.wowzer.net/code/MCC_Design_Pattern_Draft.doc> .
I look forward to hearing from you on it.
thanks,
-bryan costanich
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
|
| |
|
|
| |
|
| |
| Deyan Petrov |
MessageHi Bryan,
I think I understand your pattern, and I think that I understand the ECC desing pattern too. My comments were/are not specific to your MCC pattern only, but also apply to the ECC design pattern.
You have not answered my questions, though - if you look in my previous post there are 3 concrete questions. First I asked you where exactly you place the business logic (this has nothing to do with db operations). After that I asked you if the Manager's responsibility is to retrieve/update/delete ONLY or it has additional functionality. And lastly I asked you how usable an isDirty flag can be, without caring where else (ECC) this flag is used.
Another question which I preserved for this second email concerns a distributed scenario. How do you support distrubuted scenario with your pattern? Are all the classes/collections/engines supposed to be on the client (Web server, winform app etc.) or on the applicaton server, or you always assume that physically the web server and the app server will be on the same machine? If your classes are .NET remoted? I think this is not possible neither with your pattern, nor with the ECC desing pattern, because of heavy and mulitiple network roundtrips because of the fine grained class properties/operations and the lack of a Business/Session/whatever Facade.
And also - how do you handle transactions spanning several engines/collections/classes? How about (centralised) security? Without centralised Facade you can't do that. And please don't tell me you are going to use COM+ from within .NET, with the ultrafast COM Interop and nice "shadow-copy" deployment and transaction attributes at the class level in COM+ ;)
Have a nice vacation! I am heading for a one too :)
Regards,
Deyan Petrov
----- Original Message -----
From: Bryan Costanich
To: aspngarchitecture
Sent: Thursday, July 04, 2002 3:13 AM
Subject: [aspngarchitecture] Re: MCC Design Pattern
Deyan,
I believe you've misunderstood the pattern, but that's clearly my fault in it's presentation.
The manager's responsibility is exactly as you described PersistenceManager, I will add a section that describes the responsibilities of the objects.
The dirty flag is the same as in the ECC design pattern. Actually these patterns are very similar, except that much of the functionality of the collection has been moved to the Manager so that we can have lightweight bindable collections that are reusable.
To delete an object, let's call it user, from the datastore one would call the UserManager.DeleteUser() method, and you might pass in an ID, or simply the User object. You might also have a Data Accesss Layer behind that abstracts away your datasource and so UserManager might call a DAL.DataManager.DeleteUser() or the like.
I would write more, but I'm heading off for vacation.
Thanks for the feedback, it's clear that there is some ambiguity in the doc.
-b
-----Original Message-----
From: Deyan Petrov [mailto:Click here to reveal e-mail address]
Sent: Wednesday, July 03, 2002 9:34 AM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MCC Design Pattern
Hi Bryan,
I find some problems with your pattern and I am sorry to say that I wouldn't agree to use it.
First the place of the business methods/rules is not obvious. Where should I place my Business methods? In the Class, in the Collection, in the Manager or everywhere? If I place it in the class or collection, then if these are transported over the network to the client and the client tries to execute them?
Second, the responsibility of the manager is not clear enough. I think that there should be a PersistenceManager, which should deal with retrieving/updating the class and collection ONLY. There should be another entity, which should have the business methods/rules in it.
Third, the isDirty flag is not very clear. What means that an object is dirty? Is it a newly created object, modified or deleted?
I have been clearing out a .NET distributed application design during the last few weeks, I think that now I am near to clearing it out. In it the central point is that the objects have externalized state, which can be transported to the client, and there are a set of services available - like PersistenceManagers, TransactionManager, SecurityManager, ExceptionManager etc. 10x to this listserver for a recent descussion "Is this a good object desing", by the way...
Regards,
Deyan Petrov
----- Original Message -----
From: Bryan Costanich
To: aspngarchitecture
Sent: Wednesday, July 03, 2002 7:02 AM
Subject: [aspngarchitecture] MCC Design Pattern
All,
Some time ago, in the neighborhood of 8 months ago captured a pattern that is similar to the ECC pattern but a lot simpler and more .NET friendly while being every bit as robust.
The pattern had a great reception and in fact was very familiar to a lot of people, hence it being a pattern, and I got a lot of good feedback on completing the pattern. However, I never got around to finishing it up.
I'm going to be releasing another draft of it pretty soon, but I was hoping that I could get some feedback on it's current state.
You can find the pattern at http://codebox.wowzer.net/code/MCC_Design_Pattern_Draft.doc.
I look forward to hearing from you on it.
thanks,
-bryan costanich
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
|
| |
|
| |
|
| |
| Brian Espey |
Deyan,
if I understand the pattern correctly it looks like
the business methods would go in the manager class.
the persistence methods would go there as well, but
might delegate to some other layer for the actual SQL
calls. as far as remoting goes, it looks the "class"
objects are perfect for that. they are simple value
objects, easily remoted across the network. regarding
the isDirty flag, i'm curious about that as well; i'd
like to see a more detailed explanation of how that
would be used (maybe a sample of how to use it in the
context of a web application).
for transaction control, is there any reason he
couldn't use something like the declarative
transaction component you designed? what makes you
think MCC precludes declarative transactions? it
seems like you could just have a controller object
(like a Session facade) above the Manager object, and
it would be responsible for calling the different
Manager objects in the correct sequence. the
transaction could start at the level of this
controller object, and it would be responsible for
calling SetComplete. the Manager objects could be
declared to participate in the transaction, and they
would know to call SetAbort whenever an error occurs
(I guess this might force you to have instances of the
Manager objects, rather than just static methods, but
the pattern would still work essentially the same way)
for centralized security, if you implement the data
access calls through some other service layer,
couldn't it all be there?
Brian
--- Deyan Petrov <Click here to reveal e-mail address> wrote:
[Original message clipped]
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
|
|
|
| |
|
| |
|
| |
| Deyan Petrov |
Hi Brian,
I don't like a Manager class, doing Persistence and Business logic at the
same time.
As for transactions and security - the proper place is the Business Facade.
Then you need a much simpler data access component (and faster), to pick up
the transaction/connection from the CallContext and that's it - very simple.
Regards,
Deyan Petrov
----Original Message Follows----
Deyan,
if I understand the pattern correctly it looks like
the business methods would go in the manager class.
the persistence methods would go there as well, but
might delegate to some other layer for the actual SQL
calls. as far as remoting goes, it looks the "class"
objects are perfect for that. they are simple value
objects, easily remoted across the network. regarding
the isDirty flag, i'm curious about that as well; i'd
like to see a more detailed explanation of how that
would be used (maybe a sample of how to use it in the
context of a web application).
for transaction control, is there any reason he
couldn't use something like the declarative
transaction component you designed? what makes you
think MCC precludes declarative transactions? it
seems like you could just have a controller object
(like a Session facade) above the Manager object, and
it would be responsible for calling the different
Manager objects in the correct sequence. the
transaction could start at the level of this
controller object, and it would be responsible for
calling SetComplete. the Manager objects could be
declared to participate in the transaction, and they
would know to call SetAbort whenever an error occurs
(I guess this might force you to have instances of the
Manager objects, rather than just static methods, but
the pattern would still work essentially the same way)
for centralized security, if you implement the data
access calls through some other service layer,
couldn't it all be there?
Brian
--- Deyan Petrov <Click here to reveal e-mail address> wrote:
[Original message clipped]
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
|
|
|
| |
|
|
| |
|
|
|
|
|
|
|
|
BootFX
Reliable and powerful .NET application framework. |
|
|
|
|
|
|
