سؤال

حسنا, لذلك كنت أحاول وضع كل واحد من الفصول في المجلد الجذر ، إما:

واجهة المستخدم
BusinessLogic
DataAccess
BusinessObjects
واجهات

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

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

  2. الحدث Arg الطبقات ؟

أيضا ، في إطار مشروع أنا الآن أن نبدأ النظم الفرعية التي يكون كل 3 (البيانات الوصول إلى الكائنات الأعمال ، busiensslogic).كيف يجب أن تفكك بنية المجلدات?

A.

ProjectX
--Subsystem1
----BusinessObjects
----DataAccess
----BusinessObjects
--Subsystem2
----BusinessObjects
----DataAccess
----BusinessObjects

أو

ProjectX
--BusienssLogic
----Subsystem1BL
----Subsystem2BL
--DataAccess
----Subsystem1DA
----Subsystem2DA
--BusinessObjects
----Subsystem1BO
----Subsystem2BO

أو

ProjectX
--BusinessLogic
--DataAccess
--BusinessObjects
(مع عدم وجود الدلائل لكل وظيفية الفرعي)

هل كانت مفيدة؟

المحلول

وأنا أحاول أن محاذاة بلدي الجمعية الأسماء مع مساحات و استخدام .صافي الإطار نفسه كمبدأ توجيهي.أؤمن بأن العمل مع مساحة الهيكل الذي يدفع بنية المجلد يجعل أكثر للصيانة تعليمات البرمجة الأساسية.

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

[الشركة].الأساسية.البيانات.التخزين المؤقت

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

[الشركة].الأساسية.البيانات.محولات
[الشركة].الأساسية.البيانات.المحولات
[الشركة].الأساسية.البيانات.التخزين المؤقت
[الشركة].الأساسية.البيانات.مولدات

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

اسم المشروع هو جذر اسم المجلد.هذا يفترض مصدري التحكم في مجلد ، الذي هو "C:\Source السيطرة" على الجهاز المحلي:

C:\Source التحكم\الأساسية[الشركة].الأساسية.البيانات\
C:\Source التحكم\الأساسية[الشركة].الأساسية.البيانات\محولات
C:\Source التحكم\الأساسية[الشركة].الأساسية.البيانات\التخزين المؤقت
C:\Source التحكم\الأساسية[الشركة].الأساسية.البيانات\المحولات
C:\Source التحكم\الأساسية[الشركة].الأساسية.البيانات\مولدات

وهذا التسلسل الهرمي ، يبدو شيئا مثل:

[حل]
--[الشركة].الأساسية.البيانات
----[محولات]
------(محولات الملفات)
----[المؤقت]
------(التخزين المؤقت الملفات)
----[محولات]
------(محولات الملفات)

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

لقد تم القيام بذلك لسنوات حتى الآن, و أنها مريحة جدا ليس فقط نفسي ، ولكن بالنسبة لي للمطورين لاستخدام.

كما EventArgs السؤال ، أنا أتفق مع الآراء التي كنت تفعل في العادة فئة واحدة لكل ملف ، ولكن سوف تجعل استثناء لوضع EventArgs فئة مع فئة أخرى إذا كان المفرد الاستخدام.بالنسبة multiuse, أنا وضعت لهم على أعلى نقطة المنطقية في الجمعية ، مما يتيح مساحة هيكل إلى ربط بلدي النطاق.

نصائح أخرى

أنا عادة أحب التمسك الفئة 1 ، 1 ملف القاعدة ، ولكن عندما يتعلق الأمر EventArgs, أود فعلا أن تعلن لهم في نفس الملف الذي يمكنني تحديد مندوب أو الحدث.ما لم يكن ، وسائط يتم استخدامها من قبل أكثر من فئة واحدة الهرمي التي لا تميل إلى أن يحدث لي في كثير من الأحيان.

أما ذاكرة التخزين المؤقت ، وأود أن وضع في مجلد من الفئات التي تدعم.

بقدر ما أحب التنظيم الجيد ، يمكن للمرء أيضا الحصول على الشرج مع ذلك.

هذا هو الغالب الذوق الشخصي.

أنا أتفق مع ما بريان Genisio قال بخصوص مكان وضع EventArg الطبقات.... الخ:إذا كنت لا تستعمل إلا مرة واحدة ، ووضعها في نفس الملف حيث يمكنك استخدامها.بالنسبة دروس عامة/files, أنا دائما "العامة" المجلد (كيف مريحة!;-))

وفيما يتعلق بنية المجلد:كنت أذهب مع واحد ثاني, هذا هو واحد من 3 طبقات و تحافظ على النظم الفرعية فصل.الفوز!

أنا فقط أريد أن أضيف تعليق على الأسماء.أشعر كلمة التجارية يؤدي إلى سوء الاستخدام.فعلنا هذا, و الآن نحن لا نعرف ما هو حول:المجال المنطق أو طبقة الخدمة.أود أن أقترح أسماء مثل المجال.المجال.Impl (فصل واجهات من Impl) ثم خدمات و ربما استمرار إذا كنت تستخدم ORM...قد تكون مختلفة إذا كان لديك باستخدام نهج مختلف ، ولكن أن نكون صادقين, أنا في حيرة عن أسماء BusinessLogic, Access, و BusinessObjects.أنا لا أفهم ما هو ما.BusinessObjects يجب أن تحتوي على منطق الأعمال ، منطقي ؟ أم أنها مجرد DTOs?ثم لماذا هم في مشروع منفصل من Access?

ليس هناك طريقة صحيحة واحدة للقيام بذلك.

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

آسف, لقد غاب عن C# الوسم.أمثلة جيدة .صافي المشاريع التي تم تغطيتها من قبل هنا و هنا.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top