Thông báo


Chia sẻ
Tùy chọn
Xem bài viết cuối
Offline admin  
#1 Đã gửi : 10/06/2016 lúc 02:44:36(UTC)

Danh hiệu: Administration

Chức danh:

Nhóm: Administrators
Gia nhập: 23-07-2013(UTC)
Bài viết: 6,117
Viet Nam
Đến từ: Vietnam

Cảm ơn: 10 lần
Được cảm ơn: 2 lần trong 2 bài viết

Logging Approach

In principle where some dependency exists between a class and a service it requires the service should be provided using some dependency resolution mechanism that supports loose coupling. In practice it is a massive overhead explicitly to provide every class that may want to write a log message with an interface it can log against. In addition, it may be argued that logging is sufficiently ubiquitous that the use of a logger does not need to be advertised in class constructors.

Instead some sources recommend the use of an ambient context of logging, which is a pattern where the service is available to any potential consumer via a static property. In a way, that is what we have with the log at the moment, but it is possible to envisage an implementation which decouples the process of writing a log message to a static logger from the handling of that message, and this is what we should aim for.

Logging Approach

The key features are as follows:

  • Log messages originate from the business logic, which calls a static method on a singleton log object and does not know the details of the implementation.

  • The static log write to a log interface, which may be supplied when the application starts, but which always has a default implementation.
  • For production code there is a concrete logger that implements the interface and that receives log messages and publishes them to subscribers.
  • Subscriptions for log messages are specified with a filter that indicates the characteristics of log messages required by the subscriber. Filter criteria might include log level or type (error, warning, trace, debug &c) or context (such as application component, comms session ID &c).
  • Different subscribers may be used in different applications, or event in the same application. In the example shown there is a file logger that writes messages to a file and a database logger that writes them to a database table. The filtering mechanism means they may receive different log messages.
  • For test code there is a concrete test logger that receives log messages and saves the to a collection, so they may be validated as part of the test results evaluation.

This is just an example, but is designed to demonstrate the key features of a more flexible logging framework. There are some additional factors that need to be kept in mind:

  • Still has the problem that the single instance is not available in a secondary AppDomain, but we can envisage ways around that, including wiring the instance in the secondary AppDomain up to the one in the primary.
  • The log currently performs other functions such as accumulating log messages and raising error events int “Exception Handling”. These would be more properly performed outside the log, and are covered below.

  • The current log message class has support for some context information (log sender, session ID, file ID &c) but we will need to consider making the context mechanism extensible.

There is an alternative view that logging should only ever be achieved through the use of aspects (AOP). However, it is unlikely that we will use aspects in the absence of native support in C#, and anyhow AOP is best suited to tracing (method calls) rather than logging business logic.

Ai đang xem chủ đề này?
OceanSpiders 2.0
Di chuyển  
Bạn không thể tạo chủ đề mới trong diễn đàn này.
Bạn không thể trả lời chủ đề trong diễn đàn này.
Bạn không thể xóa bài của bạn trong diễn đàn này.
Bạn không thể sửa bài của bạn trong diễn đàn này.
Bạn không thể tạo bình chọn trong diễn đàn này.
Bạn không thể bỏ phiếu bình chọn trong diễn đàn này.

| Cung cấp bởi YAF.NET | YAF.NET © 2003-2021, Yet Another Forum.NET
Thời gian xử lý trang này hết 0.231 giây.