клиент(1) -> службы (2) -> службы доступа к данным(3) -> БД

AK>клиент(1) -> службы (2) -> службы доступа к данным(3) -> БД
AK>

Step 2 – Determine Where to Cache Data


When deciding on where to cache data, there are typically two things you must consider: the physical location of the cache, and the logical location of the cache.

The physical location will either be in-memory, or disk-based using files or a data-base. In-memory caching may be performed using the ASP.NET cache mechanism, Enterprise Library Caching Application Block, or a distributed in-memory caching mechanism such as Microsoft project code named “Velocity” or the Danga Interactive “Memcached” technology. An in-memory cache is a good choice when the data is used frequently by the application, the cached data is relatively volatile and must be frequently reacquired, and the volume of cached data is relatively small. A file system-based or database cache is a good choice when accessing data from the cache store is more efficient when compared to acquiring the data from the original store, the cached data is relatively less volatile, and the services for reacquiring the data are not always available. The disk-based approach is also ideal when the volume of cached data is relatively large, or the cached data must survive process and machine restarts.

The logical location of the cache describes the location within the application logic. It is important to cache the data as close as possible to the location where it will be used to minimize processing and network round trips, and to maximize the performance and responsiveness of the application. Consider the following guidelines when deciding on the logical location of the cache data:

* Consider caching on the client when the data is page specific or user specific, does not contain sensitive information, and is lightweight.

* Consider caching on a proxy server or Web server (for Web applications) when you have relatively static pages that are requested frequently by clients, your pages are updated with a known frequency, or the results are returned from Web services. Also, consider this approach where you have pages that can generate different output based on HTTP parameters, and those parameters do not often change. This is particularly useful when the range of outputs is small.

* Consider caching data in the presentation layer when you have relatively static page outputs, you have small volumes of data related to user preferences for a small set of users, or you have UI controls that are expensive to create. Also consider this approach when you have data that must be displayed to the user and is expensive to create; for example, product lists and product information.

* Consider caching data in the business layer when you must maintain state for a service, business process, or workflow; or when relatively static data is required to process requests from the presentation layer and this data is expensive to create.

* Consider caching data in the data layer when you have input parameters for a frequently called stored procedure in a collection, or you have small volumes of raw data that are returned from frequently executed queries. Consider caching schemas for typed datasets in the data layer.

* Consider caching in a separate table inside the database any data that requires considerable query processing to obtain the result set. This may also be appropriate when you have very large volumes of data to cache, where you implement a paging mechanism to read sections of the data for display in order to improve performance.

D>>А я кеширую только в DAL. Мне так легче следить, чтобы вовремя сбрасывать/корректировать кеши, когда один и тот же DAL из разных BL цепляется. Локализация ответственности, в общем.

package model
case class Section(id: Int, ownerId: Int)
case class Nofification (id: Int, postId: Int, sectionId: Int)

package modelx
case class SectionX (o: Section, owner: User)
case class NofificationX (o: Notification, post: Post, sectionX: SectionX)

object NotificationDAL {
    private val byUserIdCache = new MapCache[Int, List[NotificationX]](maxElements_? = Some(10))
    def getForUser(userId: Int) = byUserIdCache(userId, userId => {
        // запрос (notification join post join (section join user)),
        // возвращающий List[NotificationX]
    })
}