Cubes3DIntersection is a web application to check if two 3D cubes collide and, eventually, calculate the intersected volume. It is built following the requirements: https://documentcloud.adobe.com/link/track?uri=urn:aaid:scds:US:e0a740b7-d870-4727-87cc-fb9815734b15.
Tests are automatically verified:
Use these instructions to get the project up and running.
You will need the following tools:
Follow these steps to get your development environment set up:
- Clone the repository
- At the root directory, restore required packages by running:
dotnet restore- Next, build the solution by running:
dotnet build- Next, within the Cubes3DIntersection.Api directory, launch the back end by running:
dotnet run- Launch http://localhost:44340/ in your browser to view the Swagger UI documentation.
If you have Visual Studio after cloning, click on Open solution with your IDE and Cubes3DIntersection.Api should be the start-up project. Directly run this project on Visual Studio with F5 or Ctrl+F5. You will see index page of project, you can navigate product and category pages and you can perform crud operations on your browser.
The project uses a persistent database, even if the default configuration of Entity Framework Database is "InMemoryDatabase". After cloning or downloading the solution, you will need to run its Entity Framework Core migrations before you will be able to run the app. You can see the ConfigureDatabases method in Startup.cs (see below).
public void ConfigureDatabases(IServiceCollection services)
{
// use in-memory database
//services.AddDbContext<Cube3DIntersectionDbContext>(c =>
// c.UseInMemoryDatabase("Cubes3DIntersectionConnection")
// .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking));
// use real database
services.AddDbContext<Cubes3DIntersectionDbContext>(c =>
c.UseSqlServer(Configuration.GetConnectionString("Cubes3DIntersectionConnection"))
.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking));
}-
Ensure your connection strings in
appsettings.jsonpoint to your local SQL Server instance. -
Open a command prompt in the Web folder and execute the following commands:
dotnet restore
dotnet ef database update -c Cube3DIntersectionDbContext -p ../Cubes3DIntersection.Infrastructure/Cubes3DIntersection.Infrastructure.csproj -s Cubes3DIntersection.Api.csprojOr you can direct call ef commands from Visual Studio Package Manager Console. Open Package Manager Console, set default project to Cubes3DIntersection.Infrastructure and run below command;
update-databaseThese commands will create Cubes3DIntersection database. You can see from Cube3DIntersectionDbContext.cs.
- Run the application. The first time you run the application, it will seed Cubes3DIntersection sql server database.
If you modify-change or add new some of entities to Core project, you should run ef migrate commands in order to update your database as the same way but below commands;
add migration YourCustomEntityChanges
update-databaseCubes3DIntersection implements NLayer Hexagonal architecture (Core, Application, Infrastructure and Presentation Layers) and Domain Driven Design (Entities, Repositories, Domain/Application Services, DTO's...). Also implements and provides a good infrastructure to implement best practices such as Dependency Injection, logging, validation, exception handling and so on. Aimed to be a Clean Architecture also called Onion Architecture, with applying SOLID principles. Also implements and provides a good infrastructure to implement best practices like loosely-coupled, dependency-inverted architecture
Cubes3DIntersection include layers divided by 4 project;
- Core
- Entities
- Interfaces
- ValueObjects
- Exceptions
- Application
- Interfaces
- Services
- Models (DTOs)
- Mappers
- Exceptions
- Extensions
- Factories
- Infrastructure
- Data
- Repository
- Services
- Migrations
- Logging
- Exceptions
- Api
- Controllers
- Views
Abstraction of a Generic Repository (IGenericRepository) for CRUD operations on Domain objects. This interface include database operations without any application and ui responsibilities.
Implementation of Core interfaces in this project with Entity Framework Core and other dependencies. Most of your application's dependence on external resources should be implemented in classes defined in the Infrastructure project. These classes must implement the interfaces defined in Core. If you have a very large project with many dependencies, it may make sense to have more than one Infrastructure project (eg Infrastructure.Data), but in most projects one Infrastructure project that contains folders works well. This could be includes, for example, e-mail providers, file access, web api clients, etc. For now this repository only dependend sample data access and basic domain actions, by this way there will be no direct links to your Core or UI projects.
Includes Entity Framework Core Context and tables in this folder. When new entity created, it should add to context and configure in context. The Infrastructure project depends on Microsoft.EntityFrameworkCore.SqlServer and EF.Core related nuget packages, you can check nuget packages of Infrastructure layer. If you want to change your data access layer, it can easily be replaced with a lighter-weight ORM like Dapper.
EF add-migration classes.
EF Repository implementation. This class is responsible for the database operations
Custom services implementation, like email, cron jobs etc.
Development of Domain Logic with implementation. Interfaces drives business requirements and implementations in this layer. In this layer we can add validation , authorization, logging, exception handling etc. -- cross cutting activities should be handled in here.
Development of Api Logic with implementation. Interfaces drives business requirements and implementations in this layer. The application's main starting point is the ASP.NET Core web project. This is a classical console application, with a public static void Main method in Program.cs. It currently uses the default ASP.NET Core project template which based on Razor Pages templates. This includes appsettings.json file plus environment variables in order to stored configuration parameters, and is configured in Startup.cs.
For each layer, there should be a test project which includes intended layer dependencies and mock classes. So that means Core-Application-Infrastructure and Api layer has their own test layer. By this way this test projects also divided by unit, functional and integration tests defined by in which layer it is implemented. Test projects using xunit and Mock libraries. xunit, because that's what ASP.NET Core uses internally to test the product. Moq, because perform to create fake objects clearly and its very modular. Due to time constraints, instead of unit tests for all the projects, some tests made with postman have been added.
- .NET Core 3.1
- ASP.NET Core 3.1
- Entity Framework Core 3.1
- .NET Core Native DI
- AutoMapper
- Clean Architecture
- Full architecture with responsibility separation of concerns
- SOLID and Clean Code
- Domain Driven Design (Layers and Domain Model Pattern)
- Unit of Work
- Repository and Generic Repository
- Monolitic Deployment Architecture
- This repository is not intended to be a definitive solution.
- This repository not implemented a lot of 3rd party packages, we are try to avoid the over engineering when building on best practices.
- Beware to use in production way.
Thanks to the following people who have contributed to this project:
If you want to contact me you can reach me at daniele.crivello84@libero.it.
This project uses the following code of conduct: CODE_OF_CONDUCT.
This project uses the following license: MIT.