Làm thế nào để ngăn chặn các phương thức truy cập dữ liệu trùng lặp lấy dữ liệu tương tự?

Trong hầu hết mọi dự án tôi làm việc với một nhóm, cùng một vấn đề dường như xuất hiện. Ai đó viết mã UI cần dữ liệu và viết phương thức truy cập dữ liệu:

AssetDto GetAssetById(int assetId)

Một tuần sau, một người khác đang làm việc trên một phần khác của ứng dụng và cũng cần một AssetDtonhưng bây giờ bao gồm cả 'người phê duyệt' và viết như sau:

AssetDto GetAssetWithApproversById(int assetId)

Một tháng sau, ai đó cần một tài sản nhưng bây giờ bao gồm 'câu hỏi' (hoặc 'chủ sở hữu' hoặc 'yêu cầu đang chạy', v.v.):

AssetDto GetAssetWithQuestionsById(int assetId)
AssetDto GetAssetWithOwnersById(int assetId)
AssetDto GetAssetWithRunningRequestsById(int assetId)

Và nó thậm chí còn tồi tệ hơn khi các phương pháp như GetAssetWithOwnerAndQuestionsByIdbắt đầu xuất hiện.

Bạn thấy mô hình nổi lên: một đối tượng được gắn vào biểu đồ đối tượng lớn và bạn cần các phần khác nhau của biểu đồ này ở các vị trí khác nhau.

Tất nhiên, tôi muốn ngăn chặn việc có một số lượng lớn các phương thức gần như giống nhau. Nó chỉ đơn giản là một vấn đề kỷ luật nhóm hoặc có một số mô hình tôi có thể sử dụng để ngăn chặn điều này? Trong một số trường hợp, có thể có các phương pháp riêng biệt, nghĩa là có được một tài sản với các yêu cầu đang chạy có thể tốn kém vì vậy tôi không muốn bao gồm các phương thức này mọi lúc. Làm thế nào để xử lý các trường hợp như vậy?

Cú pháp khôn ngoan, tôi sẽ tạo một đối tượng xây dựng truy vấn trung gian với giao diện trôi chảy:

// all the basic, cheap to query fields
AssetDto a = AssetRetriever(asset_id).fetch() 

// some common expensive fields
AssetDto a = AssetRetriever(asset_id).withOwner().withQuestion().fetch() 

// numerous less common fields may not command dedicated methods
AssetDto a = AssetRetriever(asset_id).withFields("foo", "bar").fetch() 

// Better yet, use an enum and enjoy static checking
AssetDto a = AssetRetriever(asset_id).withFields(F_OWNER, F_QUESTION).fetch() 

Tôi hy vọng nó đủ rõ ràng để thực hiện. Phương pháp duy nhất sẽ thực sự chạm vào cơ sở dữ liệu là fetch().

Khi làm việc với đối tượng lớn, điều này thực sự phổ biến. Trong khi thêm các phương thức mới làm tăng hiệu suất, nó làm giảm đáng kể khả năng bảo trì. Và một lần nữa bạn cần phải chọn giữa hai.

Tôi đề nghị bạn nên có một phương thức trả về (không nhất thiết là dữ liệu nhỏ nhất) thường được sử dụng, một phương thức khác trả về toàn bộ đối tượng và có thể thêm một vài cho các tài nguyên đắt nhất.

Một cách tiếp cận khác là có các phương thức chỉ trả về các trường cần thiết của đối tượng, như AssetQuestions GetAssetQuestionsById(int assetId)hoặc Owners GetAssetOwnersById(int assetId).

Cùng với điều này, bạn cần thiết lập một số quy tắc liên quan đến việc truy xuất dữ liệu. Ví dụ, nếu ai đó cần 5 trường của đối tượng và có một phương thức hiện có trả về 8, thì nên sử dụng phương thức hiện có.

Gần đây tôi đã trải qua vấn đề tương tự và áp dụng giải pháp sau:

Các phương thức truy cập dữ liệu chỉ nên lấy dữ liệu từ một tài nguyên duy nhất (ví dụ: bảng cơ sở dữ liệu) và nếu quy trình cần các đối tượng liên quan được gắn vào đối tượng chính thì nó sẽ gọi phương thức chịu trách nhiệm cho các đối tượng tương ứng đó.

Theo cách này, nếu bạn cần một tài sản với những người phê duyệt, bạn nên tạo một phương thức mặt tiền để tham gia vào các đối tượng.

Thí dụ:

public Class AssetFacade {

   public AssetDto getAssetWithQuestionsByAssetId(int assetId) { 

      AssetDto asset = AssetDao.getAssetById(assetId);
      List<QuestionDto> questions = AssetDao.getQuestionsByAssetId(assetId);
      asset.setQuestions(questions);

      return asset;
   };
 }

Nó chỉ đơn giản là một vấn đề kỷ luật nhóm hoặc có một số mô hình tôi có thể sử dụng để ngăn chặn điều này?

Vâng, đó là vấn đề của một số hướng dẫn trong cách đặt tên cho nhóm. Bạn có thể đặt 4 phương thức đơn giản như GetEntityById (), Get ALLEntities (), SetEntity (), DeleteEntityById ().

Ngoài ra, bạn có thể có hai dto với cách đặt tên AssetSimpleDto GetAssetById(assetId)và một dto chi tiết khác được gọi là AssetDto GetAssetDetailById(assetId). Phương pháp đầu tiên và dto được tùy chỉnh để mang lại mức tối thiểu, trong khi thứ hai là mang tất cả thông tin liên quan mà chức năng của bạn có thể cần.