أن المجلدات في حل تتناسب مع مساحة?

Question

أن المجلدات في حل تتناسب مع مساحة?

في واحد من فريقي المشاريع لدينا مكتبة فئة يحتوي على العديد من المجلدات الفرعية في المشروع.

اسم المشروع و مساحة: MyCompany.Project.Section.

ضمن هذا المشروع ، هناك العديد من المجلدات التي تتناسب مع مساحة المقطع:

• المجلد Vehicles وقد دروس في MyCompany.Project.Section.Vehicles مساحة
• المجلد Clothing وقد دروس فيMyCompany.Project.Section.Clothing مساحة
• الخ.

داخل نفس هذا المشروع هو آخر المارقة مجلد

• المجلد BusinessObjects وقد دروس في MyCompany.Project.Section مساحة

هناك عدد قليل من مثل هذه الحالات حيث المجلدات مصنوعة "التنظيمية الراحة".

سؤالي هو:ما هو المعيار ؟ في مكتبات فئة فعل المجلدات عادة ما تتناسب مع مساحة هيكل أو مختلطة الحقيبة ؟

Answer 1

لاحظ أيضا أنه إذا كنت تستخدم المدمج في قوالب لإضافة فصول مجلد ، فإنه سيتم بشكل افتراضي في مساحة الاسم التي تعكس التسلسل الهرمي للمجلد.

الفئات التي سوف يكون من الأسهل العثور وهذا وحده يجب أن تكون أسباب جيدة بما فيه الكفاية.

القواعد التي نتبعها هي:

• المشروع/الجمعية اسم هو نفس مساحة الاسم الجذر ، باستثناء .dll تنتهي
• إلا استثناء على القاعدة المذكورة أعلاه هو المشروع .الأساسية تنتهي،.جوهر هو خلع
• المجلدات يساوي مساحات
• نوع واحد في ملف (الطبقة البنية, التعداد, مندوب, الخ.) يجعل من السهل العثور على الملف الصحيح

Answer 2

لا.

لقد حاولت كل الطرق على المشاريع الصغيرة والكبيرة سواء مع واحد (لي) و فريق من المطورين.

وجدت أبسط وأكثر إنتاجية الطريق كان لديك واحد مساحة كل مشروع و كل الطبقات تذهب إلى أن مساحة الاسم.يمكنك بعد ذلك وضع الطبقة الملفات في أي مشروع المجلدات التي تريدها.لا يوجد العبث مضيفا باستخدام البيانات في الجزء العلوي من الملفات في كل وقت كما أن هناك واحد فقط مساحة الاسم.

من المهم أن تنظيم الملفات المصدر في مجلدات و في رأيي أن كل المجلدات ينبغي أن تستخدم.تتطلب هذه المجلدات أيضا خريطة مساحات لا لزوم لها ، يخلق المزيد من العمل و وجدت فعلا ضارة المنظمة لأن إضافة عبء تشجع الفوضى.

خذ هذا التقدم تحذير على سبيل المثال:

CA1020:تجنب مساحات مع بعض أنواع
السبب:مساحة أخرى من مساحة العالمي على أقل من خمسة أنواع https://msdn.microsoft.com/en-gb/library/ms182130.aspx

هذا التحذير تشجع إلقاء ملفات جديدة في عام المشروع.العامة أو مجلد أو حتى الجذر المشروع حتى يكون لديك أربعة فصول مماثلة لتبرير إنشاء مجلد جديد.سوف أي وقت مضى أن يحدث ؟

العثور على الملفات

الجواب المقبول يقول "الطبقات سوف يكون من الأسهل العثور وهذا وحده يجب أن تكون أسباب جيدة بما فيه الكفاية."

وأظن الجواب مشيرا إلى وجود عدة مساحات في المشروع الذي لا خريطة بنية المجلد بدلا من أن ما أقترحه هو مشروع مع مساحة اسم واحد.

في أي حال حين لا يمكنك تحديد المجلد الذي فئة الملف في مساحة الاسم, يمكنك العثور عليه باستخدام الذهاب إلى تعريف أو البحث في "مستكشف الحلول" مربع في Visual Studio.أيضا هذا ليس حقا مشكلة كبيرة في رأيي.لا تنفق حتى 0.1% من وقت التطوير على مشكلة إيجاد الملفات لتبرير تحسين ذلك.

اسم الاشتباكات

متأكد من خلق مساحات متعددة يسمح المشروع إلى فئتين بنفس الاسم.لكن هل هذا حقا شيء جيد ؟ هو ربما من الأسهل أن مجرد عدم السماح التي من الممكن ؟ مما يسمح فئتين بنفس الاسم يخلق الوضع أكثر تعقيدا حيث 90% من الوقت عمل الأشياء بطريقة معينة ثم فجأة تجد لديك حالة خاصة.نقول لديك اثنين المستطيل فئات محددة في مساحات منفصلة:

• فئة مشروع1.صورة.المستطيل
• فئة مشروع1.نافذة.المستطيل

فمن الممكن أن تصل قضية مصدر الملف يجب أن تشمل كلا من مساحات الأسماء.الآن لديك لكتابة كامل مساحة في كل مكان في هذا الملف:

var rectangle = new Project1.Window.Rectangle();

أو تعبث مع بعض سيئة باستخدام البيان:

using Rectangle = Project1.Window.Rectangle;

مع مساحة اسم واحد في المشروع الخاص بك كنت اضطر إلى الخروج مع مختلف ، ويهمني القول وصفية أكثر الأسماء مثل هذا:

• فئة مشروع1.ImageRectangle
• فئة مشروع1.WindowRectangle

والاستعمال هو نفسه في كل مكان, لم يكن لديك للتعامل مع حالة خاصة عند ملف يستخدم كلا النوعين.

باستخدام البيانات

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

مقابل

using Project1;

سهولة عدم الحاجة إلى إضافة مساحات طوال الوقت أثناء كتابة التعليمات البرمجية.انها ليست الوقت الذي يستغرقه حقا إنه كسر في التدفق من الاضطرار إلى القيام بذلك فقط ملء الملفات مع الكثير من استخدام البيانات من أجل ماذا ؟ هل الأمر يستحق ؟

تغيير مجلد المشروع هيكل

إذا المجلدات التي تم تعيينها إلى مساحات ثم مجلد المشروع المسار فعال ترميز-الثابت في كل ملف المصدر.وهذا يعني أن أي إعادة تسمية أو نقل ملف أو مجلد في المشروع يتطلب الفعلية محتويات الملف إلى تغيير.كل من مساحة الإعلان من الملفات في هذا المجلد باستخدام البيانات في مجموعة كاملة من الملفات الأخرى التي تشير دروس في هذا المجلد.في حين أن التغيرات ذاتها هي تافهة مع الأدوات ، فإنه يؤدي عادة في ارتكاب كبيرة تتكون من العديد من الملفات التي دروس لم يتغير.

مع مساحة اسم واحد في المشروع يمكنك تغيير مجلد المشروع بنية ومع ذلك تريد دون أي مصدر الملفات أنفسهم يجري تعديلها.

Visual Studio تلقائيا خرائط مساحة من جديد الملف إلى مجلد المشروع هو خلق في

مؤسف, ولكن أجد عناء تصحيح مساحة أقل من المتاعب من التعامل معهم.أيضا حصلت في العادة من نسخ ولصق ملف موجود بدلا من استخدام إضافة->جديد.

التحسس الذكي "مستعرض الكائنات"

أكبر فائدة في رأيي من استخدام عدة مساحات في المشاريع الكبيرة هو وجود اضافية المنظمة عند عرض دروس في أي الأدوات التي يعرض دروس في مساحات الهرمي.حتى وثائق.من الواضح وجود واحد فقط مساحة في المشروع النتائج في جميع الفئات التي يتم عرضها في قائمة واحدة بدلا من تقسيمها إلى فئات.ومع ذلك شخصيا لم يسبق لي الحيرة أو تأخر بسبب عدم وجود هذا حتى لا تجد فائدة كبيرة بما يكفي لتبرير مساحات متعددة.

على الرغم من أن إذا كنت أكتب كبير الطبقة العامة المكتبة ثم أن ربما استخدام عدة مساحات في المشروع بحيث الجمعية بدا أنيق في الأدوات و الوثائق.

Answer 3

أعتقد القياسية داخل .NET هو أن تحاول أن تفعل ذلك عندما يكون ذلك ممكنا ، ولكن ليس لخلق داع البنى العميقة فقط التمسك أنها القاعدة الصلبة.أي من مشاريعي اتبع مساحة == هيكل القاعدة 100% من الوقت في بعض الأحيان فقط نظافة/أفضل للخروج من هذه القواعد.

في جافا لم يكن لديك خيار.أنا أسمي هذه حالة كلاسيكية من ما يعمل في نظرية مقابل ما يعمل في الممارسة العملية.

Answer 4

@lassevk:وأنا أتفق مع هذه القواعد ، و أكثر واحد لإضافة.

عندما يكون لدي الطبقات المتداخلة ، ما زلت تقسيمها ، واحدة لكل ملف.مثل هذا:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

و

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

Answer 5

أنا أقول نعم.

أولا سوف يكون من الأسهل العثور على الفعلية ملفات التعليمات البرمجية التالية إلى أسفل مساحات (القول عند شخص ما رسائل البريد الإلكتروني لك عارية استثناء استدعاء المكدس).إذا كنت اسمحوا الخاص بك المجلدات الذهاب متزامنة مع مساحات إيجاد الملفات كبيرة codebases يصبح الحصول على متعب.

الثانية, مقابل سيتم إنشاء فصول جديدة تقوم بإنشائها في المجلدات مع نفس مساحة الأم بنية المجلد.إذا كنت ترغب في السباحة ضد هذا سوف يكون هناك واحد فقط أكثر السباكة عمل يوميا عند إضافة ملفات جديدة.

بالطبع هذا من نافلة القول أن المرء يجب أن يكون المحافظ عن مدى عمق xis مجلد/مساحة الهرمي يذهب.

Answer 6

نعم أنها ينبغي أن لا يؤدي إلى الارتباك على خلاف ذلك.

Answer 7

ما هو المعيار ؟

لا يوجد المعيار الرسمي ولكن تقليديا المجلد إلى مساحة رسم النمط هو الأكثر استخداما على نطاق واسع.

في مكتبات فئة فعل المجلدات عادة ما تتناسب مع مساحة هيكل أو مختلطة الحقيبة ؟

نعم ، في معظم مكتبات فئة المجلدات تتناسب مع مساحة التنظيمي سهولة.