A RepositoryManager?

Re: A RepositoryManager

My opinion is that Repositories should support transaction but not
initialize transactions. Transaction should be initialized and
controlled from the upper/facade level.

For example:

public class CustomerRepository
{
    IDatabase database; //can be passed in from constructor

    public Customer Find(int customerID) {
        DataSet customerData =
database.ExecuteProcedure("FindCustomer", customerID);
        return BuildCustomerFormDataSet(customerData);
    }

    public void Update(Customer customer) {
        database.ExecuteProcedure("UpdateCustomer",
customer.ID,customer.Name, customer.etc...);

    }
     //....
}

At facade (service level, method is called from client apps):

public void UpdateCustomerAddress(int customerID, Address address)
{
    CustomerRepository repository = new
CustomerRepository(MySQLDatabase); 

    Customer customer = repository.Find(customerID);
    customer.Address = address;

    using (TransactionScope transactionScope = new TransactionScope())
    {
         repository.Update(customer);

         transactionScope.SetComplete(); //commit, otherwise roll back
which is handled by "using"
    }
} 

--- In domaindrivendesign <at> yahoogroups.com, Joey Samonte <dyowee23@...>
wrote:
>
> Good day to all!
>   From my current understanding of repository, you usually would
have one repository for each entity you have in your domain model. But
how do you manage database connection, transaction between all your
repositories? Do you need to create a RepositoryManager to handle
connections, transactions, and all your repositories? Any code samples?
>    
>   Thank you very much.
> 
>        
> ---------------------------------
> Looking for last minute shopping deals?  Find them fast with Yahoo!
Search.
>

 

Re: A RepositoryManager?

Re: Re: A RepositoryManager

Re: A RepositoryManager?

Re: A RepositoryManager?

Re:Changing identifiers

I understand what you mean by having the update() method in the
repository check for uniqueness.  That's kind of what I was hoping for.

I'm less clear on what you mean by distinguishing between change the
values in the domain object versus saving the object into the repository.

I mean, in theory I understand what you mean.  I'm just not sure
exactly how to implement it in my scenario.  Right now, I'm at the
very beginnings of the project and haven't implemented any kind of
persistent backend, so I've just been creating repositories that store
objects in-memory - some collection, like a set or map, depending on
the situation.

So I think part of my problem is that updating a domain object causes
the object in the repository to be changed directly.  And the plan is
to eventually move to something like Hibernate, where the persistence
will be transparently done.  So there isn't really a _need_ for an
update() method.  I could change the behaviour of my in-memory
repository to return a copy of the actual object and create an update
method that has to be called for any changes to be persisted.

Another problem is that I haven't added any surrogate IDs at this
point because I was thinking of them as purely backend issues.  Now
I'm starting to think that I'll need a surrogate ID as part of the
domain model so that in the repository I can find any object with the
same natural identifier as the object passed into the update() method
and check to see if the surrogate IDs match.  If there is an object
with the same natural identifier and the surrogate IDs are the same,
the the natural identifier isn't changing.  If they don't match, then
I can't do the update because an object with the natural identifier
already exists.  If there is no object with that same natural
identifier then I can go ahead and perform the update. 

Does all this sound reasonable/workable?  Is there anything I'm
forgetting?

Thanks for the input, I really appreciate it.
Rich

--- In domaindrivendesign <at> yahoogroups.com, "Bill Hamaker"
<BillHamaker@...> wrote:
>
> I think the normal approach would be to have Update be a method in your
> repository so uniqueness is always checked by the repository.     You
> need to distinguish between changing the unique values in the domain
> object versus saving the domain object into the repository.
> 
>  
> 
> If you wanted to check for uniqueness ahead of time I would have a
> CheckForUniqueness methods in the repository also.
> 
>  
> 
> Bill Hamaker
> 
> 
> 
> CONFIDENTIALITY NOTICE:
> 
> The information contained in this message may be privileged and
confidential. It may also be protected from disclosure or be a
> privileged work product or proprietary information. This information
is intended for the exclusive use of the addressee(s). If you are not
the intended recipient, please notify the sender immediately by
replying to this message and you are hereby notified that any use,
disclosure,
> dissemination, distribution (other than to the addressee[s]),
copying or taking of any action because of this information is
strictly prohibited.
> 
> Thank you,
> 
> Marvin F. Poer and Company
>

 

Re: A RepositoryManager?

Re: A RepositoryManager?

Re: Best way to orchestrate methods when using DDD

On Thu, Jan 31, 2008 at 9:01 AM, kaushik_spock <kaushik.spock <at> gmail.com> wrote:
> We are trying out DDD in our project and have been stuck with some
>  issues on the best way of orchestrating method calls across multiple
>  domain objects.
>
>  We have 3 domain objects - Order, Ticket and Block. The relationship
>  between them is as follows
>
>  - Order can have one to many Tickets
>  - Block can have one to many Tickets
>
>  We are using hibernate as our ORM tool. So we can navigate between
>  any entity. So to go from order to block (or vice versa), we
>  navigate from order to ticket and from ticket to its owning block.
>
>  From the GUI we can call operations like cancel on any of the domain
>  objects. If Cancel is called on any one entity, it requires all
>  other entities to be cancelled as well.
>  - If cancel on order/ticket is called, ticket/order will be
>  cancelled and block may be cancelled based on some conditions.
>
>  Options tried
>
>  - Cancel methods in each object which would also call cancel on one
>  other entity. So the block's cancel method would be responsible for
>  calling cancel on both ticket and ticket will call order's cancel
>  method. This seems to be messy and leads to circular calls.

It's easy to break the cycle by introducing some temporary variables
to signal methods in progress:

Order.cancel() {
    if (this.cancelling) return;
    this.cancelling = true;
    doCancel();
    cancelAll(ticket);
    this.cancelling = false;
}

Ticket.cancel() {
    if (this.cancelling) return;
    this.cancelling = true;
    doCancel();
    this.order.cancel();
    this.cancelling = false;
}

This stuff is plain boilerplate but may become too messy. OTOH if
you're modelling these as explicit state transitions then the
infrastructure code can deal with this current transition issue and
avoid infinite cycles.

>  - Distinct methods for each flow possible, cancelFromBlock ,
>  cancelFromTicket but this seems to lead to method explosion as
>  methods for all possible calls need to be present in all 3 objects
>
>  We are now thinking the best way is to have cancel methods on each
>  object that will just cancel itself. Some orchestrator method/object
>  somewhere would calls these methods in proper sequence. We are not
>  sure where this method belongs.
>
>  - Where do such orchestrator methods belong ? Should this be present
>  in a service or should it be part of the domain object itself as a
>  value object.
>  - If we use services, how should the service get a reference to the
>  domain object from hibernate? Should it talk to the DAO directly to

>  load the domain object directly ?
>
>  Thanks in Advance for the help.

Best regards,
Daniel Yokomizo