I read that carefully. And yes very helpful!
Assuming you have following products and namespaces
Microsoft.Dynamics.Inventory is a DLL Microsoft.Dynamics.Bank is a DLL
Each of above have (Views, Reports, Utils, etc)
Should I go for that?
Microsoft.Dynamics.Inventory.Sales.Reports Microsoft.Dynamics.Inventory.Sales.Views Microsoft.Dynamics.Inventory.Sales.Controls Microsoft.Dynamics.Inventory.Purchase.Reports Microsoft.Dynamics.Inventory.Purchase.Views Microsoft.Dynamics.Inventory.Purchase.Controls
Or Go for that? (Currently used)
Microsoft.Dynamics.Inventory.Reports.Sales Microsoft.Dynamics.Inventory.Views.Sales Microsoft.Dynamics.Inventory.Controls.Sales Microsoft.Dynamics.Inventory.Reports.Purchase Microsoft.Dynamics.Inventory.Views.Purchase Microsoft.Dynamics.Inventory.Controls.Purchase
When you write
using directives the first one appears good. But the folder structures will be bad.
- If I use second approach I got very good structured folders See Image
- If I use first approach each Sub-Module have Views, Reports, Controls (Duplicated)
Please its not opinion based. I actually afraid for a bad structured later will become worse.
I can’t imagine an example with
System.Data.SqlClient are not
System.Data.Common can used bellow System.Data.OleDb System.Data.SqlClient System.Data.AnyProvider
How to apply that structure to My example above?
- A Sales maybe doesn’t have Reports (So are first approach bad?)
- A Purchase maybe doesn’t have controls (So are first approach bad?)
I see that in MVC architecture they go with second approach. I don’t sure about that.
So should I fllow second approach?
If all the objects in those classes are similar then try this approach
Microsoft.Dynamics.Inventory.Reports Microsoft.Dynamics.Inventory.Views Microsoft.Dynamics.Inventory.Controls
In these object, Use something called TransactionType indicating if its a purchase or sales.
Answered By – Hamza Hussain
Answer Checked By – Timothy Miller (AngularFixing Admin)