ما هي أفضل طريقة لتنظيم مشروع؟ [مغلق

Question

كنت أتساءل عن كيفية تنظيم مشاريعي.

لدينا بعض المشاريع التي تستخدم (إعادة) في مشاريع أخرى.

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

ما أنا حقا ما أعرفه هو كيفية بناء هذا النوع من المشروع، ما هي أفضل طريقة لتسمية ذلك؟

في تطبيق قياسي 3 مستويات، يجب أن يكون مثل شيء مثل:

1. دال، dataaccesslayer، البيانات ...
2. نموذج، BusinessObject، BOL ...
3. واجهة المستخدم، عرض، ...

أي أفكار أخرى؟

في كل شركة أعمل، حصلوا على طريقة مختلفة لتنظيمها، هل هناك واحد أفضل من الآخر؟ أي واحد تستخدمه وهو الذي تفضله ولماذا؟

شكرا!

Answer 1

بالنسبة لطبقة البيانات، عادة ما أستخدمها:

company.projectname.data. (أي AdventureWorks.OrderManager.data)

بالنسبة لطبقة العمل، أفضل شيء مثل "OfficeModel" (لقد استخدمت "الأعمال" أو "الأعمال"، لكن هذه هي المنطقة التي تأتي فيها البيانات معا في الكائنات / الفئات، فلماذا لا تسمية ذلك؟).

company.projectname.objectmodel. (أي Adventureworks.OrderManager.ObjectModel)

بالنسبة ل UI، أحب إما "UI" القديم أو "العرض" ...

company.projectname.presentation. (أي AdventureWorks.OrderManager.Presentation)

Answer 2

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

Answer 3

في الغالب يمكنني استخدام بنية الطبقات على النحو الموصى به في أنماط وممارسات Microsoft تطبيق بنية ل .NET: تصميم التطبيقات والخدمات. وبعد وصف الوثيقة الهندسة المعمارية و .NET Technologies لتنفيذها.

Answer 4

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

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

لمزيد من البصيرة في هذا الموضوع الكبير، أقترح بشدة القراءة Domain Driven Design من Eric Evans و Applying Domain-Driven Design and Patterns من Jimmmy Nilsson.

Answer 5

أنا أعمل حاليا على تطبيق الويب الأمامي الذي يحتوي على بنية 3 مستويات:

• الطبقة العميل (المتصفح)
• طبقة التطبيق (خادم تطبيقات Java EE، حيث سيعيش التطبيق)
• الخلفية الطبقة (المركزية والتطبيقات القديمة، قواعد البيانات المختلفة)

لديها بنية الطبقات، والطبقات في الطبقة التطبيق هي:

• طبقة العرض التقديمي: يولد UI الذي سيتم استخدامه في الطبقة العميل
• طبقة التطبيق: ما يعادل حالات الاستخدام، يحتوي على منطق التطبيق
• طبقة الخدمة: خرائط منطق المجال والبيانات من Wind Tier على نموذج Java
• طبقة التكامل: يتواصل مع الطبقة الخلفية وتحتوي على عبارات ل JMS، البريد الإلكتروني، ... و Daos وغيرها من الأشياء

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

يمكنك إضافة / تبديل / إزالة الطبقات كما تراها مناسبة. في SOA على سبيل المثال، يمكنك طبقة طبقة WebService أعلى طبقة التطبيق أو طبقة الخدمة، بحيث يمكن أن تتصل ESB (Bus Service Service Bus) بطلبك أو خدماتك. إذا كان أي من هذا أمر مستحيل أو يبدو صعبا للغاية، فلن يكون لديك هندسة وتصميم مثالي.

عند التفكير في بنية مشروعك والسماح بسيناريوهات مثل الواحدة أعلاه، بعض الخصائص المهمة لوحداتك ومكوناتك التي تريدها هي:

• القدرة على التحصيل
• إعادة استخدام
• قابلية الصيانة

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