Rename root namespace.

[asynts]

@DoctaJonez made the suggestion to rename the root namespace to match the recommended naming convention.

There was some discussion about this and the consensus was to rename the root namespace (citation needed).

Therefor, the namespaces should start with Codidact.Core.* (?).

[ranolfi]

Please use this as reference for the approved convention: https://github.com/codidact/core/tree/ranolfi/skeleton/Solution.

One related thing that we haven't discussed AFAIK, and may, optionally, be addressed in this issue as well, is whether to have the solution actually sit at the root of the repository, or in a subdirectory, as I did (which I like to name "Solution", instead of following the "src" convention that is common for javascript -and not only -based projects).

Since it's not entirely relevant here, I won't get into the arguments for both of these (root vs. subdir, 'src' vs. 'Solution') now, unless the person who wants to take this issue wants to cover that as well.

[ranolfi]

p.s. @DoctaJonez proposed Codidact.Web.UI for the Web Application project. In my skeleton, I had used Codidact.Core.WebApplication. 'UI' is more generic of course, but 'WebApplication' may be way too specific - thoughts? @misha130, @DoctaJonez

[asynts]

I like Codidact.Core.Web or Codidact.Core.UI, adding WebApplication is a bit too verbose in my opinion.

[DoctaJonez]

It depends on the context of what other projects are going to live there, and what the solution is called.

e.g.

Option 1:

• Codidact.Core.sln
• Codidact.Core.Web.csproj (website) <-- this is the project we're discussing
• Codidact.Core.Web.ViewModels.csproj (website library)
• Codidact.Core.Web.Dtos.csproj (website library)
• Codidact.Core.Web.Contracts.csproj (website library)
• Codidact.Core.Api.csproj (api website)
• Codidact.Core.Api.Clients.csproj (client library)

vs

Option 2:

• Codidact.Core.Web.sln
• Codidact.Core.Web.UI.csproj (website) <-- this is the project we're discussing
• Codidact.Core.Web.UI.ViewModels.csproj (website library)
• Codidact.Core.Web.UI.Dtos.csproj (website library)
• Codidact.Core.Web.UI.Contracts.csproj (website library)
• Codidact.Core.Web.Api.csproj (api website)
• Codidact.Core.Web.Api.Clients.csproj (client library)

In this case, I think option 1 is more suitable. The only reason for option 2 is if we need finer granularity for other things in the Codidact.Core namespace, i.e. we have other websites that will reside within the Codidact.Core.Web namespace. That would also lead to the question of whether those other sites belong in the same repository.

The namespaces and projects suggested above are for illustration purposes, to focus on the importance of the namespace, and what pattern other projects in the solution should follow.

[ranolfi]

I like Codidact.Core.Web or Codidact.Core.UI, adding WebApplication is a bit too verbose in my opinion.

I remember naming it Codidact.Core.Web at first and then being more specific because there was (is) going to be a Codidact.Core.WebAPI project as well.

Regarding Codidact.Web.UI, I didn't want to go with that since the Web API could be considered an user interface, in the architecture we're planning.

The first point is an important one, the second, maybe not so much...

[asynts]

I remember naming it Codidact.Core.Web at first and then being more specific because there was (is) going to be a Codidact.Core.WebAPI project as well.

Good point.

Addendum. How about Codidact.Core.WebApp?

[ranolfi]

Addendum. How about Codidact.Core.WebApp?

Sounds good to me 👍