เมื่อใดควรคลาสหรือโมดูลในแอสเซมบลี / DLL แยกต่างหาก

มีแนวทางใดบ้างในการตัดสินใจว่าคลาสควรอยู่ในชุด / DLL ของตัวเองหรือไม่? ฉันมักจะเห็นโรงเรียนแห่งความคิดสองแห่ง:

1) "การจัดกลุ่ม" ของคลาสทุกคลาสนั้นอยู่ใน DLL ของตัวเองเช่นที่เก็บบริการ DTO โครงสร้างพื้นฐานเป็นต้น

2) ทุกอย่างควรอยู่ใน DLL เดียว แต่แยกออกจาก namespaces / folder เช่นมี "Core" DLL ที่มี namespaces เพิ่มเติมเช่น Core.Repositories, Core.Services, Core.DTO เป็นต้น

ที่ทำงานเราเพิ่งรวบรวมทุกอย่างในสภาเดียวที่เรียกว่า "ธุรกิจ" มีบางโฟลเดอร์ แต่ไม่มีการแยกที่แท้จริง - วัตถุทางธุรกิจ (ด้วยตรรกะซึ่งบางอันไม่ควรเป็นคลาส) จะถูกรวมเข้าในโฟลเดอร์ "BusinessObjects" โดยไม่สนใจ สิ่งที่ใช้ในคลาสมากกว่าหนึ่งอยู่ในโฟลเดอร์ "Core" ยูทิลิตี้อยู่ในโฟลเดอร์ "ยูทิลิตี้" โครงสร้างพื้นฐานการเข้าถึงข้อมูลคือโฟลเดอร์ "ข้อมูล" - คุณจะได้รับแนวคิด

สำหรับโมดูลใหม่ที่ฉันกำลังทำงานอยู่ฉันต้องการ / จำเป็นต้องมีชั้นการเข้าถึงข้อมูลแยกต่างหาก (คิดว่าเป็นการใช้งาน Repository Repository) แต่ฉันไม่ต้องการที่จะทิ้งมันไว้ในโฟลเดอร์ "BusinessObjects" กับอีก 160 (!) ชั้นเรียนที่นั่น ในเวลาเดียวกันฉันกังวลเกี่ยวกับการสร้าง Class Library ใหม่เนื่องจากทุกคนคุ้นเคยกับการบรรจุ Class ใน Library เดียว โฟลเดอร์ / namespace สามารถทำงานได้อย่างไรก็ตาม

ฉันคิดว่ามันจะดีกว่าถ้ามีโครงการเพิ่มเติม (เช่นชุดประกอบ) พร้อมคลาสที่แบ่งตามหมวดหมู่ในแต่ละโครงการมากกว่าหนึ่งโครงการที่มีคลาสทั้งหมดเหล่านี้ในเนมสเปซที่แยกต่างหาก คุณควรตั้งเป้าหมายว่าโครงการของคุณจะสามารถนำมาใช้ซ้ำได้และเพื่อแสดงเลเยอร์ต่าง ๆ ในแอปพลิเคชัน จากนั้นคุณสามารถนำโครงการเหล่านี้กลับมาใช้ใหม่ในแอปพลิเคชันในอนาคตได้โดยไม่ต้องรวมคลาสที่ไม่จำเป็นทั้งหมด

ตัวอย่างเช่นจากสิ่งที่คุณพูดถึงฉันจะมีโครงการต่อไปนี้:

• แกน
• ข้อมูล
• โดเมน (หรือ BusinessObjects)
• บริการ
• ยูทิลิตี้ (หรือผู้ช่วยเหลือ)

"ลุงบ๊อบ" Martin of Clean Code ชื่อเสียงหลักการของ SOLID ได้อธิบายหลักการสามข้อไว้ที่นี่ :

• หลักการความเท่าเทียมกันของการใช้ซ้ำในรีลีส: แกรนูลของการใช้ซ้ำเป็นแกรนูลของการปลดปล่อย
• หลักการปิดทั่วไป: คลาสที่เปลี่ยนแปลงร่วมกันจะถูกรวมเข้าด้วยกัน
• หลักการนำมาใช้ซ้ำทั่วไป: คลาสที่ใช้ร่วมกันจะถูกจัดทำแพ็กเกจด้วยกัน

กฎทั่วไปของหัวแม่มือคือคุณควรเก็บจำนวนโครงการในโซลูชันของคุณให้ต่ำที่สุด แยกพวกเขาออกหากคุณจำเป็นต้องทำเพื่อใช้เรื่องราวของผู้ใช้อย่างน้อยหนึ่งเรื่องหรือถ้ามีแอสเซมบลีเดี่ยวทำให้เกิดปัญหาประสิทธิภาพการทำงานที่วัดได้

แนวทางที่อื่นที่ฉันทำงานด้วย:

• คุณคิดว่าคุณจะใช้รหัสนี้ในโครงการอื่นอีกครั้งหรือไม่ สำหรับแอปพลิเคชันเว็บที่เกี่ยวข้องกลุ่มหนึ่งเรามีโมดูลที่เกี่ยวข้องกับบัญชีผู้ใช้หนึ่งที่แอปพลิเคชันทั้งหมดใช้เนื่องจากพวกเขาทั้งหมดใช้รูปแบบเดียวกันสำหรับบัญชีผู้ใช้และการเข้าสู่ระบบ ฉันได้ทำสิ่งที่คล้ายกันกับห้องสมุดรูปทรงเรขาคณิตและคณิตศาสตร์และนำมาใช้ใหม่ในหลายแอปพลิเคชันโดยรวมถึง DLL

• คุณต้องการที่จะสามารถแก้ไข / ปรับใช้รหัสนี้โดยไม่ต้องใช้งานซ้ำ / การคอมไพล์โครงการใหม่ทั้งหมดหรือไม่ บางครั้งการสร้างโมดูลใหม่ให้ปรับใช้และรีสตาร์ทเว็บแอปพลิเคชันจะเป็นประโยชน์

ดูเหมือนว่าในกรณีของคุณ Repository พื้นฐานและทั่วไปอาจมีประโยชน์อีกครั้งในอนาคตมันอาจคุ้มค่าที่จะแยกมันออกเป็น DLL ใหม่ถ้าคุณทำได้