Create ready made project with Milvasoft.Helpers
- Install the latest .NET Core SDK and Visual Studio 2019
- Run
dotnet new --install Milvasoft.Templates.Web.Mongo
to install the project template. - Run
dotnet new milvawebmongo --help
to see how to select the feature of the project. - Run
dotnet new milvawebmongo --name
"MyProject" along with any other custom options to create a project from the template.
dotnet new --install Milvasoft.Templates.Web.Mongo
to install the project template.Note : If you select "Place solution and project in same directory" box, you need add project to solution with "Add New Existing Project" like down below;
- Localization : Contains localization key-value pairs.
- Entity : Contains database related models. Under normal circumstances, the entity layer is not created as a separate project. It is a folder within the data layer. We prefer this structure, as creating the Entity as a layer facilitates us in establishing business logics using with the Assembly class.
- Data : Database connections are made here.
- API : This is the executable part of the project. All the business logic happens here. Endpoints and project-specific business logics written for the client are written here. Project configurations, files that will/will not be served to the Client are here.
There are Resources folder for hold localization key-value pairs language by language.
-
Each file name has the language code at the end. According to these language codes, we do it in order to use the Localization structure built in .Net Core. Resx file without language extension code is the default language file. We did this to get rid of magic strings using auto generated code.
-
SharedResource.cs is a dummy class for access localization key-value pairs.
- Classes in Collections folder in this layer represents database collections,
- Classes in EmbeddedDocuments folder in this layer represents embedded documents,
- Utils folder contains helper classes to this models.
- Database seed made with DataSeed.
Under normal circumstances, the Services folder and a few more folders are created in Core named layer. We see the layer we call API as the Business layer in other companies projects. Since project dependencies do not change, we use it this way because managing them as folders in the same layer increases efficiency rather than creating separate layers for them.
- wwwroot : Contains public static files.
- AppStartup : Contains application startup configuration.
- Controllers : Contains endpoints which public to client. No business logic here. All controllers are similar.
- DTOS : Contains Data Transfer Objects open to the client. It provides abstraction of entity models, that is, database structure, from the client.
- Middlewares : It contains custom middlewares running on the project.
- Migrations : It includes automatically generated migrations and Data Seed components.
- Services : The business logic of the whole project is here. This is the most complicated place. Endpoints call these service methods, and the service methods provide the necessary business logic and perform the related operation(data update in database etc.).
- StaticFiles : Contains private static files. It can be html files to be sent as mail.
- FodyWeavers.xml : It is the configuration file of the Fody library that we use to avoid writing ConfigureAwait(false) at the end of asynchronous methods in the whole project.
- ProjectName.API.xml : It is an xml file that is automatically created as a result of the summary we have written. We create Open Api documentation from this file with the Swashbuckle library. If you change a summary, rebuild project for recreate this file.
- Entity
- Localization
- Data
- API