❔ Naming Conventions N-Tier architecture, conflicts?
Hey!
Would like to hear additional feedbacks regarding this naming approach and a suggestion to solve conflicts.
The general naming idea is explained in details here -
https://softwareengineering.stackexchange.com/a/259840/429884
The summarize example would be (Taking User entity as example) -
*If the logic class gets too big we break it down to CQRS classes.
Following the convention above how would you avoid explicitly writing namespaces between the Model layer and the Business layer?
For example, you have this namespace in your Model layer -
ProjectName.Models.User With a class called - User.cs.
And this namespace in your Logic layer - ProjectName.Logic.User with a class called - UserLogic.cs.
You can't use User.cs in UserLogic.cs without specifying its entire namespace as User is part of the Logic namespace
What do you think?
thx!3 Replies
there is nothing wrong with writing out namespaces when referencing types
that's what namespaces are FOR
if it were me, this would be the structure
alternatvely,
Entity.cs instead of Model.csIf thats an a-ok practice I'll keep it as is and write the namespaces explcity when needed.
In regards to your structure, I don't feel comfortable enough to put all my trust on the namespace 😅
Thanks!
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.