views:

32

answers:

3

I see heavy use of "store" objects in the web app I am working on. Is there a name for this pattern and would you say these types are in the BLL or DAL?

These stores contain fragments of what I would consider a classical DAL type, associated with a single type.

For example, we have a TabStore containing methods for the persistance and retrieval of Tabs. Within each method in the TabStore there is code to invoke the appropriate NHibernate query.

What are the pitfalls (if any) of working with this pattern? Is it really a simple attempt to separate what might once have been a monolithic Dal type into more manageable, smaller types?

Example method:

public IList<Tab> GetAllTabInstancesForUserId(Guid userId)
{
    IList<Tab> tabInstances =
                UoW.Session.CreateQuery("from Tab t where t.UserId=:userId order by t.TabOrder")
                   .SetGuid("userId", userId)
                   .SetCacheable(true)
                   .List<Tab>();

    return tabInstances;
}
+1  A: 

If I understand the question correctly, "stores" are more related to DAL than to BLL, since there should be little logic in them - after all their role is just "storing".

Otávio Décio
+1  A: 

Some more details would definitely be helpful, including code snippets where the 'store' is used...

But based on what you have in your question, it sounds like the developers used the term 'store' instead of 'Repository' which implies the Repository Pattern (which are related to your Data Acess Layer).

After your update...it definitely seems like what the developers originally called a 'store' is a 'repository'.

Justin Niessner
+2  A: 

It may be what is more commonly known as a Repository.

The abstract Repository belongs in the Domain Model, but should be implemented by concrete classes in a separate Data Access Component.

Mark Seemann
Is it valid to have the data access component simply be a type (e.g. TabRepository) residing in the same DLL and namespace as the business logic?
Ben Aston
Validity depends on your needs and the complexity of the application, but for even intermediate complexity I would advise against it, as it makes it very difficult to ensure loose coupling in practice. It simply becomes too easy to make a tight coupling between consumer and concrete type.
Mark Seemann