সাবলীল ইন্টারফেসগুলি বৈশিষ্ট্যের চেয়ে আরও নমনীয় এবং কেন?

15

একটি EF 4.1 কোড প্রথম টিউটোরিয়ালে নিম্নলিখিত কোড দেওয়া হল:

public class Department
{
    public int DepartmentId { get; set; }
    [Required]
    public string Name { get; set; }
    public virtual ICollection<Collaborator> Collaborators { get; set; }
}

তারপরে এটি ব্যাখ্যা করা হয় যে অনর্গল ইন্টারফেসটি আরও নমনীয়:

ডেটা টীকাগুলি অবশ্যই ব্যবহার করা সহজ তবে এমন একটি প্রোগ্রাম্যাটিক পদ্ধতির ব্যবহার করা আরও ভাল যা আরও অনেক নমনীয়তা সরবরাহ করে।

অনর্গল ইন্টারফেস ব্যবহারের উদাহরণ দেওয়া হল:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Department>().Property(dp => dp.Name).IsRequired();
    modelBuilder.Entity<Manager>().HasKey(ma => ma.ManagerCode);
    modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .IsConcurrencyToken(true)
        .IsVariableLength()
        .HasMaxLength(20);
}

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

আমার প্রশ্ন হ'ল বিশেষত এই ক্ষেত্রে গুণাবলী ব্যবহারের চেয়ে কেন অনর্গল ইন্টারফেসটি আরও ভাল বিকল্প হতে পারে?

(দ্রষ্টব্য: আমি সাবলীল ইন্টারফেসের সম্পূর্ণ ধারণায় বেশ নতুন, সুতরাং দয়া করে এ সম্পর্কে কোনও পূর্ববর্তী জ্ঞান আশা করি না))

তথ্যসূত্র: http://codefirst.codeplex.com/

c# coding-style

— Tjaart
সূত্র

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

— এসভিউক

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

— Tjart

13

ডেটা টীকাগুলি স্থিতিশীল, উদাহরণস্বরূপ এই পদ্ধতির ঘোষণাটি রানটাইমের সময় পরিবর্তন করতে পারে না:

  [MinLength(5)]
  [MaxLength(20,ErrorMessage="Le nom ne peut pas avoir plus de 20 caractères")]
  public new string Name { get; set; }

সাবলীল ইন্টারফেস গতিশীল হতে পারে:

   if (longNamesEnabled)
   {
      modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .HasMaxLength(100);
   }
   else
   {
      modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .HasMaxLength(20);
   }

কোড উল্লেখ না করে বৈশিষ্ট্যগুলির মধ্যে পুনরায় ব্যবহার করা যেতে পারে।

— গ্যারেট হল
সূত্র

2

আপনি কেন ভাবেন যে একই সম্পত্তিটির দৈর্ঘ্য (বা অন্য কোনও সম্পত্তি) রান-টাইমে পরিবর্তিত হবে?

— ইউসুবভ

1

@ ইলিউসুবভ: আমি কোডিংয়ের সময় ক্ষেত্রের দৈর্ঘ্য জানি না এমন পরিস্থিতিতে আমি শুরু করব start

— ওয়াইয়াট বার্নেট

@ ওয়াইটবার্নেট: কেবলমাত্র কোনও পরিষেবা বা বহিরাগত আন-টাইপযুক্ত উত্স থেকে ডোমেন প্যারামিটারগুলি ডায়নামিকভাবে আনা হলে ক্ষেত্রের দৈর্ঘ্যটি একটি পরিবর্তনশীল হিসাবে বোধ করা হতে পারে। তবে, ডোমেনের বৈশিষ্ট্যগুলির সাথে গতিশীলভাবে মোকাবেলা করার জন্য রক্ষণাত্মক কোডিং পদ্ধতির প্রয়োজন হবে।

— ইউসুবভ

1

এল ইউসুবভের আপনার দুটি বৈশিষ্ট্য থাকতে পারে যা দৈর্ঘ্য বাদে ঠিক একই রকম হওয়া দরকার তাই আমি এগুলিকে একটি গতিবেগে রাখি যা এগুলি গতিশীলভাবে সেট আপ করে। এই কারণেই লেখক তাদের আরও নমনীয় বলেছেন।

— গ্যারেট হল

1

@ ইলিউসুবভ, আপনি প্রকল্পের সেটিংসে ক্ষেত্রের দৈর্ঘ্যকে একটি সেটিংস তৈরি করতে পারেন যা অ্যাপকনফিগ বা ওয়েবকনফিগে ফিড করে। তারপরে যদি কোনও ডাটাবেস ক্ষেত্রের দৈর্ঘ্য পরিবর্তিত হয়, আপনি অ্যাপ্লিকেশনটির পুনঃসংযোগ এবং পুনরায় চালনা ছাড়াই .config ফাইলের দৈর্ঘ্য পরিবর্তন করতে পারেন।

— ক্যারলেসা

8

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

উদাহরণস্বরূপ, এখানে কিছু জিনিস যা টীকাগুলি ব্যবহার করে নির্দিষ্ট করা যায় না:

ডেটটাইম সম্পত্তিটির যথার্থতা
সংখ্যার বৈশিষ্ট্যের যথার্থতা এবং স্কেল
স্থির দৈর্ঘ্যের হিসাবে একটি স্ট্রিং বা বাইনারি সম্পত্তি
অ-ইউনিকোড হিসাবে একটি স্ট্রিং সম্পত্তি
সম্পর্কের অন-ডিলিট আচরণ
উন্নত ম্যাপিং কৌশলগুলি

ব্যক্তিগতভাবে, আমি যখনই সম্ভব এমভিসি-র মতো অন্যান্য প্রযুক্তিও এগুলি গ্রহণ করতে পারি তাই বৈধতা সম্পর্কিত ডেটা টীকাগুলি ব্যবহার করি। অন্য কিছুর জন্য আমি সাবলীল এপিআই পছন্দ করি।

— bricelam
সূত্র

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

— Tjart

1

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

— ব্রাইসেলাম

আমি লক্ষ্য করেছি যে অনডিলিট আচরণটি কেবল সাবলীল এপিআইতে উপলব্ধ বলে মনে হয়। তারা কেন এইভাবে এটি বেছে নিয়েছিল তা আপনি ভাবতে পারেন? এই প্রশ্নটি নিয়ে আমি সত্যিই এই চেষ্টা করার চেষ্টা করছি। আপনি যদি প্রকল্পগুলির মধ্যে ক্লাস ভাগ করে নিচ্ছেন তবে POCO লঙ্ঘন একটি ভাল কারণ হতে পারে। আপনি যদি কোনও বৈশিষ্ট্য ব্যবহার করেন তবে আপনি চান না এমন কোনও সত্তা ফ্রেমওয়ার্ক নির্ভরতা টানতে পারেন!

— Tjaart

@ টাজার্ট, সঠিক কারণগুলি আমার মনে নেই। আমি কোড প্রথম বৈশিষ্ট্যের শেষের দিকে দলে যোগদান করেছি এবং এটির নকশার জন্য এখানে ছিলাম না। আমি টিম থেকে অন্য কাউকে পেতে পারি কিনা তা আমি দেখতে পাবো in

— bricelam

1

আপনার প্রশ্নের উত্তর লিঙ্কে সরবরাহ করা হয়েছে।

তারপরে আপনি এই পদ্ধতির মধ্যে আপনার ডোমেনের জন্য প্রযোজ্য আপনার সীমাবদ্ধতাগুলি সংজ্ঞায়িত করেন।

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

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

তবে বৈধতার সাধারণ পরিস্থিতিতে for প্রয়োগের কাজ করা উচিত কারণ বেশিরভাগ ক্ষেত্রে এটি কভার করা শক্ত is এবং অতিরিক্ত এটি আপনার সময় সাশ্রয় করতে পারে।

— Yusubov
সূত্র

আপনি কীভাবে ব্যাখ্যা করতে পারেন যে প্রোগ্রামেটিক উপায় আপনাকে আরও নিয়ন্ত্রণ দেয়? আমি আসলে এই মুহুর্তে এটি পাচ্ছি না।

— Tjaart

উদাহরণস্বরূপ, এটি নিন ".IsConcurrencyToken (সত্য)" - আপনি কীভাবে এটি একটি অ্যাট্রিবিউট সংজ্ঞাতে করবেন?

— ইউসুবভ

[

— কনকুরেন্সিচেক

ভাল ক্যাচ, আপনি কীভাবে "টেবিল এবং কলামগুলির মধ্যে সম্পর্ক" বর্ণনা করবেন?

— ইউসুবভ

[ফরেনকে ("পার্সনআইডি")] <- তেমন, যা সম্ভবত সম্ভবত সোজা নয় as হাশফোরিগেনকি (t => টি। প্রজেক্টআইডি), যদিও প্রয়োজনীয় সমস্ত কিছু হ'ল বিদেশী কাকে () সাবলীল ইন্টারফেসের মতো একটি ল্যাম্বডা নিতে দেওয়া। এটি এখনও অন্যটির চেয়ে কেন ভাল তা ব্যাখ্যা করে না।

— Tjart

0

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

— str8killinit
সূত্র

আপনি কীভাবে ডেটাবেসের প্রত্যাশা করছেন না এবং কীভাবে একটি সাবলীল ইন্টারফেস এটিকে ঘটতে বাধা দেয় তার উদাহরণ দিতে পারেন?

— Tjart