CODEWITHSUNDEEP
c#asp.net-mvc
xode
xode

Reputation: 101

A quick question about aggregate relational objects in MVC

I'm reading through Pro ASP.NET MVC 3 Framework that just came out, and am a bit confused about how to handle the retrieval of aggregate objects from a data store. The book uses Entity framework, but I an considering using a mini-ORM (Dapper or PetaPoco). As an example, the book uses the following objects:

public class Member {
    public string name { get; set; }
}

public class Item {
    public int id { get; set; }
    public List<Bid> bids { get; set; }
}

public class Bid {
    public int id { get; set; }
    public Member member { get; set; }
    public decimal amount { get; set; }
}

As far as I'm into the book, they just mention the concept of aggregates and move on. So I am assuming you would then implement some basic repository methods, such as:

List<Item> GetAllItems()
List<Bid> GetBidsById(int id)
GetMemberById(int id)

Then, if you wanted to show a list of all items, their bids, and the bidding member, you'd have something like

List<Item> items = Repository.GetAllItems();

foreach (Item i in items) {
   i.Bids = Repository.GetBidsById(i.id);
}

foreach (Bid b in items.Bids) {
   b.Member = Repository.GetMemberById(b.id);
}

If this is correct, isn't this awfully inefficient, since you could potentially issue thousands of queries in a few seconds? In my non-ORM thinking mind, I would have written a query like

SELECT
    item.id,
    bid.id,
    bid.amount,
    member.name
FROM
    item
    INNER JOIN bid
        ON item.id = bid.itemId
    INNER JOIN member
        ON bid.memberId = member.id

and stuck it in a DataTable. I know it's not pretty, but one large query versus a few dozen little ones seems a better alternative.

If this is not correct, then can someone please enlighten me as to the proper way of handling aggregate retrieval?

Upvotes: 2

Views: 869

Answers (6)

syclee
syclee

Reputation: 697

You can treat the read (query) and the write (command) side of the model separately.

When you want to mutate the state of your Aggregate, you load the Aggregate Root (AR) via a repository, mutate its state using the intention revealing public methods on the AR, then save the AR with the repository back again.

On the read side however, you can be as flexible as you want. I don't know Entity Framework, but with NHibernate you could use the QueryOver API to generate flexible queries to populate DTO's designed to be consumed by the client, whether it be a service or a View. If you want more performance you could go with Dapper. You could even use Stored Procs that projects itself to a DTO, that way you can be as efficient in the DB layer as possible.

Upvotes: 0

gekowa
gekowa

Reputation: 452

Using what kind of data access method depends on your project.

Convenience vs performance.

Using EF or Linq to SQL really boosts the coding speed. When talking about performance, you really should care about every sql statement you deliver to the database.

No ORM can do both.

Upvotes: 0

codeprogression
codeprogression

Reputation: 3441

An aggregate is a collection of related data. The aggregate root is the logical entry point of that data. In your example, the aggregate root is an Item with Bid data. You could also look at the Member as an aggregate root with Bid data.

You may use your data access layer to retrieve the object graph of each aggregate and transforming the data for your use in the view. You may even ensure you eager fetch all of the data from the children. It is possible to transform the data using a tool like AutoMapper.

However, I believe that it is better to use your data access layer to project the domain objects into the data structure you need for the view, whether it be ORM or DataSet. Again, to use your example, would you actually retrieve the entire object graph suggested? Do I need all items including their bids and members? Or do I need a list of items, number of bids, plus member name and amount for the current winning bid? When I need more data about a particular item, I can go retrieve that when the request is made.

In short, your intuition was spot-on that it is inefficient to retrieve all that data, when a projection would suffice. I would just urge you to limit the projection even further and retrieve only the data you require for the current view.

Upvotes: 2

KOTJMF
KOTJMF

Reputation: 991

This would be handled in different ways depending on your data access strategy. If you were using NHibernate or Entity Framework, you can have the ORM automatically populate these properties for you eagerly, lazy load them, etc. Entity Framework calls them "Navigation Properties", I'm not sure that NHibernate has a specific name for these "child properties" or "child collections".

In old-school ADO.NET, you might do something like create a stored procedure that returns multiple result sets (one for the main object and other result sets for your child collections or related objects), which would let you avoid calling the database multiple times. You could then iterate over the results sets and hydrate your object with all its relationships with one database call, and inside of a single repository method.

Upvotes: 1

ten5peed
ten5peed

Reputation: 15890

Where ever in your system you do the data retrieval, you would program your orm of choice to do an eager fetch of the related objects (aggregates).

Upvotes: 0

Steve Morgan
Steve Morgan

Reputation: 13091

If you use Entity Framework for you Data Access Layer, read the Item entity and use the .Include() fluent method to bring the Bids and Members along for the ride.

Upvotes: 3

Related Questions