use namespace convention

[y-code]

restructure namespace conforming to the namespace convention, which is a built-in convention in ASP.NET API Versioning.

These changes conflict with the changes in #1. It needs to be decided which to take and which to discard.

[y-code]

In my opinion, this convention does not make things easy in general after all.

API versioning can be practised by the whole API or by API endpoint.

In the case of versioning by the whole API, namespace convention may make it easy to find a source file. However, it will also cause to have more code and files. For example, when you have controller Example1 and Example2 both versioned as 1.0, and you want to make a change to Example1 as version 2.0, you will need to add new code not only for Example1 but also for Example2. Regardless the new code for Example2 of version 2 is a copy of the version 1 or just an inheritance of version 1, it is quite an extra overhead while it can be done only by one attribute. In real problems, there must be more controllers, and the more frequently you have releases, the more significant this issue will be.

On the other hand, in a context of versioning by API endpoint, such an issue does not occur. In the example above, you don't need to have any code for Example2 when releasing version 2 of Example1 because it does not have any change and thus this endpoint is still version 1. So, the namespace convention can make it easy to find a particular version of a specific controller in this context. However, as far as I know, versioning by the whole API seems to be more typical than versioning by API endpoint.

All in all, there's less chance for namespace convention to benefit us in general. As a code template, I would like to make it fit in with typical cases.

Therefore, I'm going to discard this branch.