Greetings!

I am in the early stages of the design of a large distributed enterprise application that will replace a collection of older implementations. I am highly interested in using a more pure OO design than in previous projects (a significant portion of our current implementations are Transaction Scripts), focusing more on domain models. We also would like to use as much MDD and code generation as possible, including the use of LLBLGen as the O/R Mapping solution.

The application will have a huge amount of business logic that will involve fields on mulitple entities simultaneously. When this is coupled to a technical requirement that all database actions be conducted on the app server within a COM+ security context (I plan on using Remoting to distribute the objects with a central Data Portal - ala CSLA.NET), I come to the conclusion that the Manager design pattern is the way to go.

My main issue is that I will need to create a large number of Managers, or one insanely huge Manager, and this design paradigm just smacks to me of foregoing some significant benefits of using Domain Model, not to mention it seems to cut into the total potential benefits that LLBLGen could provide.

I am wondering if I have a glaring hole in my design logic, or if this is a common design in the LLBLGen community?

Any comments that the community might have would be greatly appreciated.

Thanx,

Easy D

The number of managers should be smaller than the number of entities. You should create managers for groups of functionality in your application. With teh domain model you get the BL scattered all over the place in a lot of classes, managers allow you to avoid that.

BL can be delegated to entities though, not all BL, but some. For example: field-oriented BL rules like ID > 0 can be added to the validator classes. You can add entity-wide validation rules to implementations of IEntityValidator. The rest of the BL rules should be added to manager classes which take care of a part of the functionality, like 'order manager'.

Hi Frans (or anybody else willing to answer),

I seem to be drowning in definitions. Could you perhaps clear some things up for me? - Is a 'Manager' the same as a 'Façade'? - Is a 'Manager' the same as a 'Mediator'? - If both statements are not true, then what is a 'Manager'?

I hope someone can answer this, as I find this really frustrating.

Thnx for reading (and hopefully answering) my question(s),

Michel van den Berg

A manager 'manages' a given set of functionality. Like 'UserManager' in this forum, or 'ThreadManager'. The usermanager manages all functionality related to users. This can span multiple entities, as long as the functionality is oriented to users. Sometimes you also have managers which control other managers. You look at your functional design and you can define parts in there which are 'units', which you can see as groups of functionality. Then you define for these groups a manager each. the advantage for this is that you then have a 1:1 connection between your functional design and your actual implementation, which is key to a succesful maintainable system.

BlueCell wrote:

I seem to be drowning in definitions. Could you perhaps clear some things up for me? - Is a 'Manager' the same as a 'Façade'? - Is a 'Manager' the same as a 'Mediator'? - If both statements are not true, then what is a 'Manager'?

I hope someone can answer this, as I find this really frustrating.

Just my 2 cents.....

Welcome to the world of OOP....It took me a while and some books to fully understand this.

According to the Manager Pattern [Sommerland], it acts as a Factory [GoF] for its subjects, it's created as a singleton[GoF] and behaves as a Client-Dispatcher-Server [Buschmann].

All this means is that you have a manager creating instances for your business objects. For example, if you have an order entry system, your "manager" class would probably look like this:

public class InvoiceManager
{
          public MyInvoiceEntity getInvoice(int invoiceNumber)
          {
                 MyInvoiceEntity invoice = new InvoiceEntity(invoiceNumber);
                 .....
                 prefetchPath.Add(InvoiceEntity.PrefetchInvoiceItems).SubPath.Add(InvoiceItem.PrefetchItem)
                 ......
                 using (DataAccessAdapter adapter = new DataAccessAdapter())
                 {
                        adapter.fetchentity(invoice);
                  }
             .....
            }
                

so you get in your UI layer an instance of the invoice with all its related objects (line items, items, etc). You work on them and pass it back to the manager in order to save it....This will let you work on object instances without having to know about the DB connection....The manager instance can take care of other business rules like updating inventory status and generating inventory stock transactions.

I personally think that there are sometimes where you need to combine a domain model with the manager approach....specially with complex object models.

Hope it helps

Alfredo

Could you perhaps post a reference to this Manager Pattern [Sommerland], as I would like to read some more about it. Secondly... why did you say 'domain model"? Now you forced me to look up this new word aswell . So if it is not a too big of a problem, can we discuss the Manager Models (I asume Manager Models are models which are build using the Manager Pattern) and Domain Models? I asume we can , so here it goes:

http://dotnetjunkies.com/WebLog/seichert/archive/2004/03/13/9030.aspx This blog describes both the DM (Domain Model) and the MM (Manager Model). From what I understand is that the domain model looks very a lot like self-servicing and the manager like adapter, are they the same?

I have also read upon Frans his blog @ http://weblogs.asp.net/fbouma/archive/2004/03/06/85105.aspx. Still have some questions: - Are there any books discussing this? For example, the pros/cons for each and when to use DM over MM and vice versa?

Domain model reference: PoEAA by Martin Fowler. Also books by Evans are good sources of the domain model. Anything from Yourdon is leading you to Manager patterns. Mind you: these are most of the time not mergable.