Việc đăng nhập bên cạnh việc triển khai có vi phạm SRP không?

Khi nghĩ đến việc phát triển phần mềm nhanh và tất cả các nguyên tắc (SRP, OCP, ...) tôi tự hỏi mình cách xử lý đăng nhập.

Việc đăng nhập bên cạnh việc triển khai có vi phạm SRP không?

Tôi sẽ nói yesbởi vì việc thực hiện cũng có thể chạy mà không cần đăng nhập. Vì vậy, làm thế nào tôi có thể thực hiện đăng nhập một cách tốt hơn? Tôi đã kiểm tra một số mẫu và đưa ra kết luận rằng cách tốt nhất để không vi phạm các nguyên tắc theo cách do người dùng xác định, nhưng sử dụng bất kỳ mẫu nào được biết là vi phạm nguyên tắc là sử dụng mẫu trang trí.

Giả sử chúng ta có một loạt các thành phần hoàn toàn không có vi phạm SRP và sau đó chúng tôi muốn thêm ghi nhật ký.

• thành phần A
• thành phần B sử dụng A

Chúng tôi muốn đăng nhập cho A, vì vậy chúng tôi tạo một thành phần D khác được trang trí bằng A cả hai thực hiện giao diện I.

• giao diện tôi
• thành phần L (thành phần đăng nhập của hệ thống)
• thành phần A thực hiện I
• thành phần D thực hiện I, trang trí / sử dụng A, sử dụng L để ghi nhật ký
• thành phần B sử dụng I

Ưu điểm: - Tôi có thể sử dụng A mà không cần đăng nhập - thử nghiệm A có nghĩa là tôi không cần bất kỳ giả lập đăng nhập nào - các thử nghiệm đơn giản hơn

Nhược điểm: - nhiều thành phần hơn và nhiều thử nghiệm hơn

Tôi biết đây có vẻ là một câu hỏi thảo luận mở khác, nhưng tôi thực sự muốn biết liệu ai đó sử dụng chiến lược ghi nhật ký tốt hơn so với vi phạm trang trí hay vi phạm SRP. Điều gì về logger singleton tĩnh như là NullLogger mặc định và nếu muốn ghi nhật ký nhật ký hệ thống, người ta sẽ thay đổi đối tượng thực hiện trong thời gian chạy?

Có, đó là vi phạm SRP vì đăng nhập là mối quan tâm xuyên suốt.

Cách chính xác là ủy quyền đăng nhập vào một lớp logger (Đánh chặn), mục đích duy nhất là đăng nhập - tuân thủ SRP.

Xem liên kết này để biết ví dụ hay: https://msdn.microsoft.com/en-us/l Library / dn178467% 28v = pandp.30% 29.aspx

Đây là một ví dụ ngắn :

public interface ITenantStore
{
    Tenant GetTenant(string tenant);
    void SaveTenant(Tenant tenant);
}

public class TenantStore : ITenantStore
{
    public Tenant GetTenant(string tenant)
    {....}

    public void SaveTenant(Tenant tenant)
    {....}
} 

public class TenantStoreLogger : ITenantStore
{
    private readonly ILogger _logger; //dep inj
    private readonly ITenantStore _tenantStore;

    public TenantStoreLogger(ITenantStore tenantStore)
    {
        _tenantStore = tenantStore;
    }

    public Tenant GetTenant(string tenant)
    {
        _logger.Log("reading tenant " + tenant.id);
        return _tenantStore.GetTenant(tenant);
    }

    public void SaveTenant(Tenant tenant)
    {
        _tenantStore.SaveTenant(tenant);
        _logger.Log("saving tenant " + tenant.id);
    }
}

Lợi ích bao gồm

• Bạn có thể kiểm tra điều này mà không cần đăng nhập - kiểm tra đơn vị thực sự
• bạn có thể dễ dàng bật / tắt đăng nhập - ngay cả khi chạy
• bạn có thể thay thế ghi nhật ký cho các hình thức đăng nhập khác mà không cần phải thay đổi tệp TenantStore.

Tôi muốn nói rằng bạn đang dùng SRP quá nghiêm túc. Nếu mã của bạn đủ gọn gàng để đăng nhập là "vi phạm" duy nhất của SRP thì bạn đang làm tốt hơn 99% tất cả các lập trình viên khác và bạn nên vỗ nhẹ vào lưng.

Quan điểm của SRP là tránh mã spaghetti khủng khiếp trong đó mã làm những việc khác nhau được trộn lẫn với nhau. Trộn ghi nhật ký với mã chức năng không đổ chuông báo động cho tôi.

Không, đó không phải là vi phạm SRP.

Các tin nhắn bạn gửi đến nhật ký sẽ thay đổi vì những lý do tương tự như mã xung quanh.

Điều vi phạm SRP là gì khi sử dụng một thư viện cụ thể để đăng nhập trực tiếp vào mã. Nếu bạn quyết định thay đổi cách đăng nhập, SRP tuyên bố rằng nó sẽ không ảnh hưởng đến mã doanh nghiệp của bạn.

Một số loại tóm tắt Loggernên có thể truy cập được vào mã triển khai của bạn và điều duy nhất mà việc triển khai của bạn nên nói là "Gửi thông điệp này đến nhật ký", không có vấn đề gì về cách thức thực hiện. Quyết định về cách ghi nhật ký chính xác (thậm chí là đánh dấu thời gian) không phải là trách nhiệm của bạn.

Việc triển khai của bạn sau đó cũng không nên biết liệu logger mà nó đang gửi tin nhắn đến là a NullLogger.

Mà nói.

Tôi sẽ không đăng nhập đi vì mối quan tâm xuyên suốt quá nhanh . Phát ra nhật ký để theo dõi các sự kiện cụ thể xảy ra trong mã triển khai của bạn thuộc về mã thực hiện.

Một mối quan tâm xuyên suốt, OTOH, là theo dõi thực thi : đăng nhập vào và thoát trong mỗi phương thức. AOP là nơi tốt nhất để làm điều này.

Vì việc ghi nhật ký thường được coi là mối quan tâm xuyên suốt, tôi khuyên bạn nên sử dụng AOP để tách việc ghi nhật ký khỏi thực hiện.

Tùy thuộc vào ngôn ngữ bạn sử dụng một bộ chặn hoặc một số khung AOP (ví dụ AspectJ trong Java) để thực hiện điều này.

Câu hỏi là nếu điều này thực sự có giá trị rắc rối. Lưu ý rằng sự tách biệt này sẽ làm tăng sự phức tạp của dự án của bạn trong khi cung cấp rất ít lợi ích.

Điều này nghe có vẻ tốt. Bạn đang mô tả một trang trí khai thác gỗ khá chuẩn. Bạn có:

thành phần L (thành phần đăng nhập của hệ thống)

Điều này có một trách nhiệm: đăng nhập thông tin được truyền cho nó.

thành phần A thực hiện I

Điều này có một trách nhiệm: cung cấp việc triển khai giao diện I (giả sử tôi tuân thủ đúng SRP).

Đây là phần quan trọng:

thành phần D thực hiện I, trang trí / sử dụng A, sử dụng L để ghi nhật ký

Khi nói theo cách đó, nghe có vẻ phức tạp, nhưng hãy nhìn nó theo cách này: Thành phần D thực hiện một điều: mang A và L lại với nhau.

• Thành phần D không đăng nhập; nó ủy thác cho L
• Thành phần D không tự thực hiện; nó ủy thác cho A

Các chỉ trách nhiệm mà thành phần D có là để đảm bảo rằng L được thông báo khi A được sử dụng. Việc triển khai A và L đều ở những nơi khác. Điều này hoàn toàn tuân thủ SRP, cũng như là một ví dụ gọn gàng của OCP và việc sử dụng trang trí khá phổ biến.

Một cảnh báo quan trọng: khi D sử dụng thành phần ghi nhật ký L của bạn, nó sẽ thực hiện theo cách cho phép bạn thay đổi cách đăng nhập. Cách đơn giản nhất để thực hiện việc này là có một giao diện IL được triển khai bởi L. Sau đó:

• Thành phần D sử dụng IL để đăng nhập; một trường hợp của L được cung cấp
• Hợp phần D sử dụng I để cung cấp chức năng; một trường hợp của A được cung cấp
• Thành phần B sử dụng I; một thể hiện của D được cung cấp

Bằng cách đó, không có gì phụ thuộc trực tiếp vào bất cứ điều gì khác, giúp bạn dễ dàng trao đổi chúng. Điều này giúp dễ dàng thích ứng với thay đổi và dễ dàng giả định các bộ phận của hệ thống để bạn có thể kiểm tra đơn vị.

Tất nhiên đó là vi phạm SRP vì bạn có mối quan tâm xuyên suốt. Tuy nhiên, bạn có thể tạo một lớp chịu trách nhiệm soạn nhật ký với việc thực hiện bất kỳ hành động nào.

thí dụ:

class Logger {
   ActuallLogger logger;
   public Action ComposeLog(string msg, Action action) {
      return () => {
          logger.debug(msg);
          action();
      };
   }
}