কনফিগারেশন ম্যানেজার.AppSettings কর্মক্ষমতা উদ্বেগ

আমি আমার অ্যাপ্লিকেশন এর app.config বিভাগে (আমার ConfigurationManager.AppSettings ক্লাস ব্যবহার করে) আমার সমস্ত কনফিগারেশন সেটিংস সংরক্ষণ করার পরিকল্পনা করছি। হিসাবে ব্যবহারকারী অ্যাপ্লিকেশন এর UI (চেকবক্সে ক্লিক করে, রেডিও বোতাম, ইত্যাদি নির্বাচন) ব্যবহার করে সেটিংস পরিবর্তন, আমি যারা কোডগুলি পরিবর্তন করতে ইচ্ছুক AppSettings একই সময়ে, যখন প্রোগ্রাম চলছে তখন আমি ক্রমাগত একটি প্রক্রিয়া থেকে AppSettings অ্যাক্সেস করার পরিকল্পনা করছি যা ক্রমাগত ডাটা প্রসেস করবে। UI এর মাধ্যমে সেটিংসে পরিবর্তনগুলি রিয়েল-টাইমে ডেটা প্রক্রিয়াকরণকে প্রভাবিত করতে হবে, কেননা এই প্রক্রিয়াটি AppSettings অ্যাক্সেস করতে সক্ষম হবে

কর্মক্ষমতা সম্পর্কে এটি একটি ভাল ধারণা? লেখার সময় কনফিগারেশন সেটিংস সংরক্ষণ এবং অ্যাক্সেস করার জন্য AppSettings ব্যবহার করা "সঠিক উপায়" বলে মনে করা হয়। নোট অ্যাপ্লিকেশনগুলি, কিন্তু আমি মনে করি এই পদ্ধতিটি একটি ধ্রুবক লোডের জন্য নয় (অন্ততপক্ষে সেটিং ক্রমাগত পড়া)।

যদি কেউ এই সঙ্গে অভিজ্ঞতা আছে, আমি প্রচুর ইনপুট প্রশংসা করি।

Update: I should probably clarify a few points.

এটি একটি ওয়েব অ্যাপ্লিকেশন নয়, তাই অ্যাপ্লিকেশনটিতে একটি ডাটাবেস সংযোগ করা কেবল কনফিগারেশন সেটিংস সংরক্ষণের জন্য ওভারকিল হতে পারে। এটি একটি উইন্ডোজ ফরম অ্যাপ্লিকেশন।

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

Update 2: I accepted lomaxx's answer because Properties does indeed look like a good solution, without having to add any additional layers to my application (such as a database). When using Properties, it already does all the caching that others suggested. This means any changes and subsequent reads are all done in memory, making it extremely fast. Properties only writes the changes to disk when you explicitly tell it to. This means I can make changes to the config settings on-the-fly at run time and then only do a final save out to disk when the program exits.

এটি যাচাই করার জন্য এটি আসলে লোডকে সামলাতে সক্ষম হবে, আমি আমার ল্যাপটপে কিছু পরীক্ষা করেছি এবং প্রোপার্টি ব্যবহার করে প্রতি সেকেন্ডে 750,000 পাঠ্য এবং 7,500 লিখেছি। এটা এতদূর উপরে এবং তার চেয়েও বেশি যা আমার আবেদনটি সর্বদা এমনকি প্রয়োজনের কাছাকাছি আসতে পারত যা আমি প্রোপার্টি ব্যবহার না করেও কার্যকরীতার প্রভাব ছাড়াই বেশ নিরাপদ বোধ করি।

0
ro fr hi

8 উত্তর

আমি কেন আপনি একটি ডাটাবেসের মধ্যে ব্যবহারকারীর সেটিংস সংরক্ষণ করছি না চাইতে পারি?

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

0
যোগ

SQLite দেখুন, এটি এই বিশেষ দৃশ্যকল্প জন্য একটি ভাল বিকল্প মত মনে হচ্ছে।

0
যোগ

আমি ভুল হলে আমাকে কেউ সঠিক করে দেয়, কিন্তু আমি মনে করি না যে AppSettings সাধারণত এই ধরনের কনফিগারেশন সেটিংস জন্য ব্যবহার করা বোঝানো হয়। সাধারনত আপনি কেবল এমন সেটিংস রাখবেন যা মোটামুটি স্থিতিশীল (ডাটাবেস সংযোগ স্ট্রিং, ফাইল পাথ, ইত্যাদি) থাকবে। যদি আপনি কাস্টমাইজেবল ইউজার সেটিংস সংরক্ষণ করতে চান, তবে একটি পৃথক প্রেফারেন্স ফাইল তৈরির জন্য ভাল হবে, বা আদর্শভাবে ডাটাবেসের মধ্যে সেগুলি সংরক্ষণ করুন।

0
যোগ

আপনি যা করতে যাচ্ছেন তার জন্য অ্যাপসেটিংগুলি আসলেই অর্থবহ নয়।

যখন আপনার .NET অ্যাপ্লিকেশন শুরু হয়, এটি app.config ফাইলের মধ্যে পড়ে, এবং মেমরিতে তার বিষয়বস্তু ক্যাশ করে। এই কারণে, আপনি app.config ফাইলে লিখতে পরে, আপনি একরকম অ্যাপ্লিকেশন.config ফাইল পুনরায় প্যারেস করতে রানটাইম জোর করতে হবে যাতে এটি আবার সেটিংস ক্যাশে করতে পারেন এটি অপ্রয়োজনীয়

সেরা পদ্ধতি আপনার কনফিগারেশন সেটিংস সংরক্ষণ করার জন্য একটি ডাটাবেস ব্যবহার করা হবে।

একটি ডাটাবেস ব্যবহার ব্যতীত, আপনি সহজেই একটি বহিস্থিত xml কনফিগারেশন ফাইল সেট আপ করতে পারে। যখন আপনার অ্যাপ্লিকেশন শুরু হয়, আপনি একটি নাম ভ্যালিউএলইউএলব্লিং বস্তু বা হ্যাশটেইবল অবজেক্টে তার বিষয়বস্তু ক্যাশ করতে পারেন। আপনি সেটিংস পরিবর্তন / যুক্ত হিসাবে, আপনি যে ক্যাশে অনুলিপি এটি করতে হবে যখন আপনার অ্যাপ্লিকেশন বন্ধ হয়ে যায়, বা একটি যথাযথ সময় ব্যবধানে, আপনি ক্যাশের সামগ্রীগুলিকে ফাইলটিতে ফেরত পাঠাতে পারেন।

0
যোগ

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

এছাড়াও, যদি সম্ভব হয়, তাহলে অ্যাপ্লিকেশন সেটিংসগুলি ভাঙার দিকে তাকান। configSections যাতে আপনি লিখিত এবং ক্যাশে সম্পর্কিত সেটিংস পড়তে পারেন।

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

0
যোগ

যেহেতু আপনি একটি winforms অ্যাপ্লিকেশন ব্যবহার করছেন, যদি এটি .net 2.0 এর মধ্যে আসলে একটি ব্যবহারকারী সেটিংস সিস্টেম (বৈশিষ্ট্যাবলী) আছে যা এই উদ্দেশ্যে ডিজাইন করা হয়েছে। MSDN- এ এই নিবন্ধটি একটি সুন্দর ভূমিকা রয়েছে এই মধ্যে

If you're still worried about performance then take a look at

SQL Compact Edition which is similar to SQLite but is the Microsoft offering which I've found plays very nicely with winforms and there's even the ability to make it work with Linq

0
যোগ

ব্যবহারকারী ডেটা সংরক্ষণের জন্য আমি কনফিগার ফাইল ব্যবহার করব না। একটি ডিবি ব্যবহার করুন

0
যোগ

ডিলান,

এই উদ্দেশ্যে অ্যাপ্লিকেশন কনফিগার ফাইল ব্যবহার করবেন না, একটি এসকিউএল ডিবি (SQLite, মাইএসকিউএল, এমএসএসকিউএল, যাই হোক না কেন ব্যবহার করুন) কনফিগ ফাইলটি পড়লে এবং কনফিগার ফাইলটি সম্পর্কে লেখার সময় আপনার কম সমস্যায় পড়বে।

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

0
যোগ