Which layer do functions like: caching and logging belong?

Question

Let's say my business layer currently contains a bunch of DTO's and separate service classes to communicate with the data repository.

Example:

class PersonService
{
   IPersonRepository _personRepository;
   ILogging _logger;
   ICacheStorage _cache;
   // Constructor here to create concrete objects.

   public Person GetPersonById(int Id)
   {
       // error logging and caching here???
   }
}

Does it make sense to log and cache at this layer? Or would it make more sense for an Application Service layer to handle these concerns? Or maybe something else altogether?

score 5 · Accepted Answer · edited May 05 '11 at 14:52

5

Caching can or should be implemented whenever possible. Also caching should be transparent, so anyone who uses it shouldn't know it is actualy used. Most of the time it's logical to put it inside a data access layer, but sometimes it is logical and possible to put it in business layer too.

Logging is IMO something, that doesnt belong in any layer. It should be application-wide with one access point.

edited May 05 '11 at 14:52

Yakimych

17,612
7
52
69

answered May 05 '11 at 14:10

Euphoric

12,645
1
30
44

+1. Use caching where ever it makes sense. You could use it within the DAL so that it makes it's own life easier; and the BL might cache stuff it gets from the DAL to save on calls across the BL\DAL boundary. The latter also makes sense if the BL talks to more than one DA implementation (like a service). – Adrian K May 06 '11 at 02:44
Agree - logging is a cross-cutting concern and can go anywhere. – Adrian K May 06 '11 at 02:45

score 2 · Answer 2 · answered May 08 '11 at 09:32

Logging, and tracing, are implemented as utility classes, and invoked throughout most, or all, tiers of your architecture. Caching implementation varies by tier and by system. You can have different types of caching, and caching strategies, at different tiers, and it depends entirely upon the system in question. You might use a combination of in-process and distributed caching to achieve desired performance and consistency characteristics.

score 1 · Answer 3 · edited May 23 '17 at 12:02

1

I would say that caching is an implementation detail of the data retrieval. As far as the PersonService is concerned, it has a PersonRepository it can use to get its data. The fact that it may be in memory or in the DB is a detail it need not care about. Therefore, I say caching goes down in the data access layer.

As for logging, that can be anywhere and everywhere. There's really no "wrong" place for logging. (Which is why it is typically seen as a "cross cutting concern" and why people will use AOP for logging see discussion here: Advice on AOP with C#)

edited May 23 '17 at 12:02

Community

1
1

answered May 05 '11 at 14:03

BFree

102,548
21
159
201

How is it possible for the data access layer to know then when to expire the cache? Is this not part of the domain logic? – Henrik May 05 '11 at 14:59
@Henrik: Is it? I would argue that the expiration time is still a detail of the storage mechanism in the application, not the business side of things. – BFree May 05 '11 at 15:05
It depends. The BL of the app might well dictate when data is 'stale' and needs to be refreshed; alternatively if the data you're integrating with belongs to an external system (or systems) the decision point could well be elsewhere. – Adrian K May 06 '11 at 02:49
Some data is more volatile than other data. Non-volatile data can easily be cached without care for expiration or updating. If you can implement a push model for volatile data requiring updates, you can maintain consistency. – andrewbadera May 08 '11 at 09:30

Which layer do functions like: caching and logging belong?

3 Answers3