লগিং কোডটি ব্যবসায়ের যুক্তির বাইরে সম্পূর্ণ রাখা কি সম্ভব?


12

এওপির সাহায্যে, আমি আমার ব্যবসায়ের যুক্তি থেকে লগিং কোডটি সরিয়ে ফেলতে পারি। তবে আমি মনে করি এটি কেবল সাধারণ জিনিসগুলি লগ করতে ব্যবহার করা যেতে পারে (যেমন লগিং পদ্ধতির প্রবেশ / প্রস্থান এবং প্যারামিটারের মান)।

তবে, আমার ব্যবসার যুক্তিতে কিছু লগ করার দরকার হলে কী করব? যেমন

public void SomeDomainMethod(string id)
{
   //Get user by Id
   User user = Users.Get(id);
   if (user == null)
   {
      Log.Warn("user is not existed");        //<----------------- Log A
      throw new InvalidOperationException("user is not existed");
   }

   //Step 1 
   while(true)
   {
       //do something
   }
   Log.Info("Step 1 is completed");            //<----------------- Log B

   //Step 2
   while(true)
   {
       //do something
   }
   Log.Info("Step 2 is completed");            //<----------------- Log C

}

উপরের নমুনা পদ্ধতিটি যথেষ্ট পরিষ্কার হতে পারে না, আমি এখানে যেটি দেখাতে চাই তা হ'ল পদ্ধতিটি ডোমেন পয়েন্টের দিক থেকে সবচেয়ে ক্ষুদ্র একক হিসাবে বিবেচনা করা উচিত। এটিকে ছোট ছোট টুকরো করে ভাগ করা উচিত নয়।

পদ্ধতিটির বাইরে 3 লগিং কোডের উপরে যাওয়া কি সম্ভব? এই ধরনের পরিস্থিতির জন্য সর্বোত্তম অনুশীলন কি?


আমি নিশ্চিত যে আপনার উদাহরণের "পদক্ষেপ 1" এবং "পদক্ষেপ 2" লগগুলি ব্যবসায়ের লজিক অডিট ট্রেইলের অংশ হওয়া উচিত এবং প্রথমটি কোনও প্রযুক্তিগত লগিং। আমি প্রথমে
এইটিকে

উত্তর:


1

নিশ্চিত!

তবে আমার অভিজ্ঞতায় দুটি সাধারণ ধরণের দরকারী লগিং রয়েছে:

সমস্ত লগস: প্রোফাইলিং এপিআই এর মাধ্যমে নির্মিত লগগুলি । পারফরম্যান্স সম্পর্কিত সমস্যাগুলি সনাক্ত করতে এবং ব্যতিক্রমগুলি রিপোর্ট করার জন্য ভাল। অনেক কোলাহল পূর্ণ.

ব্যবসায়ের ইভেন্ট লগগুলি: লগগুলি ব্যবসায়িক যুক্তিযুক্ত। ব্যবসায়ের যে কোনও বিষয় যত্ন নিতে পারে। নূন্যতম আওয়াজ। কেবল উল্লেখযোগ্য, যৌক্তিক, "ব্যবসায়" ইভেন্ট। অডিটিং এবং কেপিআই এর জন্য ভাল ...

সুতরাং, আমি অত্যন্ত দুটি বিষয় সুপারিশ করব। প্রথমত, অন্যান্য রক্ষণাবেক্ষণের সরঞ্জামগুলি যেমন করুন, যেমন নতুন রেলিক করুন, এবং নেট নেট প্রোফাইলিং এপিআই 1 ব্যবহার করুন । দ্বিতীয়ত, আপনার ব্যবসার যুক্তিতে লজিকাল ব্যবসায়িক ইভেন্টগুলি লগ করুন । নির্দিষ্ট ঘটনা রেকর্ড রাখা হয় বিজনেস লজিক।

এবং, আমি সাধারণত লগিং উভয় সাজানোর জন্য Aop সুপারিশ করবে না 2 । আমার অভিজ্ঞতায় আপনি হয় সব কিছু চান , যার অর্থ আপনি কোনও প্রোফাইলার ব্যবহার করছেন বা আপনি যৌক্তিক / ব্যবসায়িক ইভেন্টগুলি চান। এবং পরবর্তী ক্ষেত্রে, আমি মনে করি এটি কেবল ব্যবসায়ের যুক্তিতে লগারকে প্রার্থনা করা আরও সহজ


1. তবে গুরুত্ব সহকারে, নিজেকে কয়েক ঘন্টা চেষ্টা করে সংরক্ষণ করুন এবং কেবলমাত্র একটি বিদ্যমান প্রোফাইলার সরঞ্জামটি ব্যবহার করুন ...

২. অবশ্যই, এটি ধরে নিয়েছে যে আপনি আমার মতামতটি ভাগ করেছেন যে ব্যবসায়ের নিয়মগুলি আড়াল করার পক্ষে একটি দিকটি দুর্দান্ত জায়গা নয়!


আমি "বিজনেস ইভেন্ট লগস" এর সাথে একমত, এবং অন্যের জবাবের মতো আমিও লগ কোডটি ব্যবসায়ের যুক্তিতে রাখব। এবং "সব কিছু লগস" অংশের জন্য, আমি এওপি সমাধানটি ব্যবহার করতে পছন্দ করি কারণ এটি এসআরপি অনুসরণ করবে এবং আমার ব্যবসায়িক যুক্তিকে কলুষিত করবে না। যাইহোক, আমি প্রথমে প্রোফাইলিং এপিআই একবার দেখে নেব।
চার্লি

10

অবশ্যই, আপনি এটির জন্য সহজেই এওপি ব্যবহার করতে পারেন। কেবল যন্ত্রাংশগুলি রিফেক্টর করুন

  • আইডি দ্বারা ব্যবহারকারী হন
  • ধাপ 1
  • ধাপ ২

মধ্যে পৃথক পদ্ধতি (আপনি পারেন করেছ উচিত আপনার কোড ক্লিনার করতে)। আপনার পছন্দের পদ্ধতির কলগুলি ( যেমন এখানে দেখানো হয়েছে ) লগ করতে এখন আপনি সহজেই আপনার এওপি ফ্রেমওয়ার্কটি কনফিগার করতে পারেন । ব্যতিক্রমটি সরাসরি কলার দ্বারা লগইন করা যেতে পারে, ব্যবসায়ের যুক্তি থেকে বেরিয়ে আসার জন্য এওপি ব্যবহার করার দরকার নেই।

আপনার সম্পাদনায়:

আমি এখানে দেখাতে চাই যে পদ্ধতিটি ডোমেন দৃষ্টিকোণ থেকে সবচেয়ে ছোট ইউনিট হিসাবে বিবেচনা করা উচিত। এটিকে ছোট ছোট টুকরো করে ভাগ করা উচিত নয়

কেন এটি করা উচিত নয়? যদি, "ব্যবসায়িক যুক্তি প্রসঙ্গে", আপনি "এমন কিছু" লগ করতে চান যা লগিংয়ের পক্ষে মূল্যবান এবং যদি এই "কিছু" কে একটি বুদ্ধিমান নাম দেওয়া যায় তবে বেশিরভাগ ক্ষেত্রেই কোডটিকে কোনও পদ্ধতিতে রিফ্যাক্টর করে তোলা অর্থ হবে? নিজস্ব. আপনি যদি এওপি ব্যবহার করতে চান তবে লগিংয়ের প্রয়োজনীয়তা নির্বিশেষে আপনার কোডটি এমনভাবে গঠন করা উচিত যা আপনার সম্ভবত এটির কাঠামোগত হওয়া উচিত। আপনি এওপি এর অসুবিধা হিসাবে এটি ব্যাখ্যা করতে পারেন, বা আপনি এটি একটি সুবিধা হিসাবে ব্যাখ্যা করতে পারেন, যেহেতু এটি আপনাকে একটি প্রতিক্রিয়া দেয় যেখানে আপনার কোডের কাঠামো উন্নত করা যায়।


এটা আমার খারাপ যে আমার উদাহরণটি যথেষ্ট পরিষ্কার নয়। আমি উদাহরণে যা দেখতে চাই তা হ'ল পদ্ধতিটি ডোমেন পয়েন্টের দিক থেকে ক্ষুদ্রতম ইউনিট যা ছোট ছোট টুকরোতে বিভক্ত হওয়া উচিত নয়।
চার্লি

@ চার্লি: উদাহরণটি পুরোপুরি পরিষ্কার। এখানে আপনার ভুল ধারণাটি সম্ভবত আপনি মনে করেন যে পদক্ষেপের চেয়ে আরও বড় পদ্ধতি থাকা ভাল ধারণা হতে পারে। এবং এটি আইএমএইচও ভুল, এটি ভাল ধারণা নয়। লগিংয়ের মূল্যবান বিভিন্ন পদক্ষেপের একটি স্পষ্ট লক্ষণ এই পদক্ষেপগুলির একটি বিমূর্ততা থাকা উচিত, নিজস্ব একটি নাম, সুতরাং নিজস্ব পদ্ধতিতে method
ডক ব্রাউন 12

@ চার্লি কিছুই আপনার ইউনিট বা কাজ দ্বারা ডাকা 3 ব্যক্তিগত পদ্ধতি করতে আপনাকে বাধা দেয়। বাইরে থেকে এই পথটি একই রকম ছিল তবে এখন আপনার লগিংয়ের জন্য প্রয়োজনীয় বিমূর্ততা রয়েছে।
রুমি

উদ্বেগগুলি লগ করে আপনি যদি আপনার কোড কাঠামোটি চালনা করতে চান তবে এই পদ্ধতিটি ঠিক আছে। যদিও কখনও কখনও আপনি এটি অন্য কোনও কিছু দ্বারা চালনা করতে চান।
জন উ

@ জনউইউ: লগিংয়ের প্রয়োজনীয়তা নির্বিশেষে কোড কাঠামোর বিভিন্ন উদ্বেগ / পদক্ষেপ প্রতিফলিত করা উচিত। যে কি কোড কাঠামো এখানে চালিত করে। এই সমস্যার সমাধান হয়ে গেলে, লগিং এওপি দ্বারা করা যেতে পারে, এটি কোডকে আরও ভাল কাঠামো দেওয়ার আরও একটি "পার্শ্ব প্রতিক্রিয়া"। সুতরাং আমি মনে করি এটি লগিংয়ের উদ্বেগ নয় যা কোড কাঠামোকে চালিত করে, এটি বেশি যে লগিংয়ের জন্য এওপি ব্যবহারের প্রয়োজনীয়তা এটি আরও স্বচ্ছ করে তোলে যে কোডটি এমন কোনও কাঠামো মিস করে যা এটির উচিত।
ডক ব্রাউন

3

লগিং স্টাফগুলি ব্যবসায়ের প্রয়োজনীয়তার অংশ না হলে আপনার কোড হিসাবে সম্পূর্ণরূপে দূরে রাখার জন্য আপনি যেমনটি বলছেন তেমন সেরা।

এর অর্থ আপনি "পদক্ষেপ 1 সম্পূর্ণ" এর মতো স্টাফগুলিতে লগইন করতে চান না। যদিও এটি প্রাথমিকভাবে ডিবাগিংয়ের জন্য কার্যকর হতে পারে তবে উত্পাদনে এটি কেবলমাত্র গিগা বাইট জঞ্জাল তৈরি করতে চলেছে যা আপনি কখনই দেখবেন না।

যদি স্টেপ 1 কমপ্লিটটি কোনও ধরণের ব্যবসায়ের ইভেন্ট হয় যার জন্য আরও পদক্ষেপ নেওয়া প্রয়োজন তবে এটি আপনাকে কোনও আইলোগার বা আপনার ক্লাসের সাথে সাদৃশ্য না দেওয়ার জন্য জোর না করে একটি ভাল পুরানো ফ্যাশন ইভেন্টের মাধ্যমে প্রকাশ করা যেতে পারে


আমি চিন্তা ছিল thats কি. আমি কোনও ডোমেন / ব্যবসায়িক মডেল পোকোর মধ্যে লগ ইন করার জন্য যুক্তিসঙ্গত কেসটি নিয়ে আসতে পারি না। লগিং এমন একটি জিনিস যা মূল ব্যবসায়িক মডেলগুলির আইএমওর বাইরে প্রাকৃতিকভাবে ফিট করে।
jleach

2

কিছু সাধারণ প্যাটার্নের সাহায্যে আপনি আপনার ব্যবসায়িক যুক্তি থেকে লগিং কোডটি বের করতে পারেন। তবে আপনি এটি করার মতো এটি খুঁজে পেতে পারেন না

উদাহরণস্বরূপ, শ্রোতার ব্যবহারের মাধ্যমে (হ্যান্ডক্রাফ্ট এক বা ইভেন্ট বাস ইত্যাদি ব্যবহার করে) আপনার কোডটি দেখতে পাবেন

public void SomeDomainMethod(string id)
{
   //Get user by Id
   User user = Users.Get(id);
   if (user == null)
   {
      listener.OnUserNotFound(userId);
      throw new InvalidOperationException("user is not existed");
   }

   //Step 1 
   while(true)
   {
       //do something
   }
   listener.OnStep1Finished(......);

   ...

}

শ্রোতার মধ্যে লগিং প্রয়োগ করে, লগিং লজিক আপনার ব্যবসায়িক যুক্তিতে আর নেই in

তবে আপনি এটি দেখতে পারেন যে এটি সর্বদা বাস্তববাদী নয় কারণ আপনি আপনার যুক্তির অর্থপূর্ণ ইভেন্টটি সর্বদা সংজ্ঞায়িত করতে সক্ষম নাও হতে পারেন।

আরেকটি পদ্ধতি হ'ল সোলারিসে ডিট্রেসের মতো প্রক্রিয়া যা আপনাকে চলমান প্রক্রিয়াগুলিতে ইনজেকশনের অনুমতি দেয় (আমি বিশ্বাস করি যে সি # তে অনুরূপ কাজ করার উপায় রয়েছে) তাই রানটাইম অনুসারে লগিং এবং পরিসংখ্যান সংগ্রহগুলি সংজ্ঞায়িত করা যায়। এখনও অন্যান্য ত্রুটি রয়েছে।


একটি সমস্যা সমাধানের চেষ্টা করছে এওপি হ'ল "ব্যবসায়িক কোড" এর সাথে সংযুক্ত নন-বিজনেস কোডের (লগিং কলগুলির মতো) কোডটি অপঠনযোগ্য হয়ে ওঠার সমস্যা। "শ্রোতা" দ্বারা "লগার" প্রতিস্থাপন করা এটি সমাধান করে না, কোডের পঠনযোগ্যতা পরিবর্তন করা হয় না
ডক ব্রাউন

2

আর একটি পদ্ধতি হ'ল ব্যবসায়ের লগিং এবং প্রযুক্তিগত লগিংকে আলাদা করা। তারপরে আমরা ব্যবসায়িক লগিংকে "অডিট" বলতে পারি এবং ব্যবসায়ের ক্রিয়াকলাপ পর্যবেক্ষণের মতো স্টোরেজ টার্ম এবং প্রসেসিং বিধিগুলির মতো ব্যবসায়ের নিয়মের একটি নির্দিষ্ট সেট প্রয়োগ করতে পারি।

অন্যদিকে, প্রযুক্তিগত লগিং, বা কেবল "লগিং", প্রযুক্তিগত সমস্যার চিহ্ন খুঁজে বের করার এক শেষ উপায়ের মাধ্যম। এটি লগ বার্তা অব্যাহত রাখতে ব্যর্থতা অসম্পূর্ণ, দ্রুত, সহনশীল হওয়া উচিত। এছাড়াও, লগ বার্তাগুলি সমস্যার উত্সের কাছাকাছি থাকা সম্ভাব্য নূন্যতম সংখ্যার মধ্য দিয়ে যেতে হবে।

লগিংয়ের লজিকটি বেশ পরিবর্তনশীল এবং বাস্তবায়নের সাথে দৃ ?়তার সাথে মিলিত হয়, তাই আপনার কি কোড থেকে আলাদা করার দরকার আছে?

নিরীক্ষার যুক্তি একটি ডোমেন যুক্তি হিসাবে বিবেচনা করা উচিত এবং সেই অনুযায়ী পরিচালনা করা উচিত।

উদাহরণস্বরূপ, ষড়ভুজ আর্কিটেকচারে ক্লায়েন্ট, স্টোরেজ এবং এমকিউ (এবং সম্ভবত, মেট্রিকস এবং কন্ট্রোল) বন্দরগুলির সাথে অডিট বন্দর থাকতে পারে। এটি গৌণ বন্দর হবে, অর্থাত্ এই বন্দরের ক্রিয়াকলাপটি বাইরের সিস্টেমগুলির পরিবর্তে ব্যবসায়িক মূল দ্বারা চালিত হয়।


আমি আপনার সাথে খুব সম্মত হয়েছি যে এখানে দুই ধরণের লগিং রয়েছে। তবে আমি লজিক অফ দ্য লগিংটি বেশ পরিবর্তনশীল এবং কার্যকরভাবে প্রয়োগের সাথে দৃ is়ভাবে মিলিত হয় না, আপনি এখানে প্রযুক্তিগত লগিং বলতে চাচ্ছেন? প্রযুক্তিগত লগিংয়ের জন্য, আমি মনে করি এটি পদ্ধতির প্রবেশ / প্রস্থান এবং প্যারামিটারের মানগুলি লগতে ব্যবহৃত হয় যা পদ্ধতির বাইরে বসে থাকা ভাল।
চার্লি

@ চার্লি হ্যাঁ, "দ্য লগিং" এর অর্থ প্রযুক্তিগত লগিং। খাঁটি ফাংশনগুলির ক্ষেত্রে প্রবেশ / প্রস্থান / পরামিতি মানগুলির লগিং যথেষ্ট। তারপরে বা অবশ্যই আপনি কোনও দিক বা লগার মোনাড ব্যবহার করতে পারেন। তবে খাঁটি ফাংশনগুলি দুর্দান্ত যে এগুলি পরীক্ষামূলক। সুতরাং, ইস্যুগুলি, লগারটি সনাক্ত করার কথা, এটি সম্ভবত ডিভ / ডিবাগের সময় সমাধান হওয়ার সম্ভাবনা রয়েছে। অপরিষ্কার ফাংশনগুলির সাথে, যেখানে টেক লগিং সর্বাধিক ব্যবহৃত হয়, আপনি প্রতি ব্যতীত প্রতিটি পার্শ্ব-কার্যকরী কল প্যারাম / ফলাফল লগ করতে চান।
iTollu

1

কোনও শ্রেণি বা পদ্ধতিতে সরাসরি লগিং এড়ানোর উপায়:

  1. একটি ব্যতিক্রম নিক্ষেপ করুন এবং কল ট্রিতে আরও দূরে কোনও ক্যাচ ব্লকে আপনার লগিং করুন। আপনার যদি কোনও লগ স্তর ক্যাপচার করতে হয় তবে আপনি একটি কাস্টম ব্যতিক্রম নিক্ষেপ করতে পারেন।

  2. লগিংয়ের জন্য ইতিমধ্যে চালিত পদ্ধতিগুলিতে কল করুন।


1
লগিংয়ের যেখানে এটি দেখা গেছে সেখানে সমস্যা রয়েছে এবং এটি "ফিক্সিং" এর মূল্যবানও কি?
কিসনেম

1

আপনার লগিংটি কি আপনার ব্যবসার যুক্তি থেকে আলাদা করার দরকার আছে? লগিং করা হচ্ছে ব্যবসায়ের যুক্তিযুক্ত লেখার সাথে চিঠিপত্র এবং তাই এটি একই বর্গ / ফাংশনে থাকা বোধ করে। আরও গুরুত্বপূর্ণ বিষয়, এটি কোডের আরও সহজ পাঠযোগ্যতার সহায়তা করে।

তবে, আপনি যদি আপনার ব্যবসায়িক যুক্তি থেকে সত্যই লগিং আলাদা করতে চান, আপনার কাস্টম ব্যতিক্রম ছুঁড়ে ফেলা এবং লগিংয়ের জন্য এই ব্যতিক্রমগুলি হস্তান্তর বিবেচনা করা উচিত।


0

না, সি # তে নয়

ওপি, আপনার নির্দিষ্ট প্রশ্নের উত্তর না, সি # তে নয়। সেখানে অন্যান্য, আরও স্থানীয়ভাবে এওপি ভাষাগুলি থাকতে পারে, তবে সি # তে এওপির সমস্ত পন্থা যা আমি দেখেছি কেবল একটি জয়েন পয়েন্টের প্রেক্ষাপটে আশাবাদী আচরণগুলি প্রয়োগ করতে পারে , যার অর্থ একটি কোড ব্লক এবং এর মধ্যে নিয়ন্ত্রণের প্রবাহ থাকতে হবে অন্য। অনুপযুক্ত আচরণগুলি অন্য কোনও পদ্ধতিতে কল করে অবশ্যই কোনও পদ্ধতির মাঝখানে কার্যকর হবে না ute

আপনি "apsect-ize" লগিংয়ের কিছু বিট করতে পারেন

বলা হচ্ছে, আপনি লগিংয়ের সাথে জড়িত কিছু উদ্বেগগুলি সরাতে পারেন, কেবল লগ রচনায় নয়। উদাহরণস্বরূপ, একটি কাটপয়েন্ট যা কোনও পদ্ধতিতে প্রবেশের সময় চালিত হয়েছিল তা লগিং প্রসঙ্গ সেটআপ করতে পারে এবং সমস্ত ইনপুট পরামিতি আউটপুট তৈরি করতে পারে এবং প্রস্থান করার সময় ব্যতিক্রমগুলি ধরতে পারে বা স্থায়ী স্টোরেজে লগ করতে পারে, এই জাতীয় জিনিস।

লগ লিখন কোনও দিকই নয়

আমি যুক্ত করব যে লগ লেখা সত্যিই কোনও ক্রস-কাটিং উদ্বেগ নয়। কমপক্ষে ডিবাগ লগিং না। এর জন্য আমার প্রমাণ হ'ল আপনি একটি ক্রস কাটিয়া প্রয়োজনীয়তা লিখতে পারেন নি যা এই দিকটি কী করবে তা পুরোপুরি ব্যাখ্যা করে - এটি প্রতিটি এবং প্রতিটি ক্ষেত্রেই সুনির্দিষ্ট, কারণ লগ লেখার উদ্দেশ্যটি যা চলছে তা প্রতিফলিত করা যুক্তি, এবং প্রতিটি পদ্ধতিতে যুক্তি যুক্তিসঙ্গতভাবে অনন্য হওয়া উচিত ( DRY দেখুন )।

অন্য কথায়, লগ লেখার এবং স্টাফ সম্পর্কে লেখা হওয়ার মধ্যে একটি অবিচ্ছেদ্য লজিকাল নির্ভরতা রয়েছে। আপনি এটি সাধারণ করতে পারবেন না।

তবে নিরীক্ষা হয়

আপনার যদি কিছু প্রকারের ক্রিয়ামূলক লগিং প্রয়োজনীয়তা থাকে (যেমন, অ-প্রত্যাখ্যান প্রয়োজনীয়তার সমর্থনে নিরীক্ষণ লগিং ) তবে কিছু তর্ক করবে (এবং আমি সম্মত হব) যে আপনি যদি কোনও পদ্ধতির মাঝখানে নিজেকে এই লগগুলি লেখার প্রয়োজন মনে করেন, আপনি আপনার কোডটি এমনভাবে গঠন করেননি যা দিক-ভিত্তিক চিন্তার সাথে সামঞ্জস্যপূর্ণ। যদি এটি ঘটে থাকে, আপনার প্রয়োজনীয় গ্রানুলারিটির স্তর না পাওয়া পর্যন্ত আপনার পৃথক পদ্ধতিতে কোডটি বের করা উচিত।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.