Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEATURE: Single file commands/queries #57

Closed
CesarD opened this issue Dec 7, 2023 · 0 comments · Fixed by #58
Closed

FEATURE: Single file commands/queries #57

CesarD opened this issue Dec 7, 2023 · 0 comments · Fixed by #58
Assignees
Labels
enhancement New feature or request

Comments

@CesarD
Copy link
Collaborator

CesarD commented Dec 7, 2023

Detailed Description

To convert the current structure that Monaco currently has about Commands/Validators and Queries folders to one where each Command and Query are placed in the same file with their corresponding handlers.
This is oriented to decompress the bloating that sometimes might affect the Commands/Queries Handlers files when there are too many commmands/queries for an entity.

Context

In order to better group together queries with their handlers and commands with their respective validators and handlers, it could be better to group each of them together in a single file, to further simplify the navigation between a query and its handler, the same as with a command with its respective validator and handler.
This should make it simpler to navigate through the structure, would align to the vertical slicing more properly, simplify handlers files that sometimes get too bloated when there are too many commands/queries, and would also simplify the testing, aligning it, as well, to the vertical slicing concept as all the tests related to a same slice would be easier to group themselves instead of having a big handlers test class that will contain all tests for all the handlers of a same entity as we currently have.
A con to this approach is that some of the shared code between some slices won't be contained in the same handlers class, within reach of all the different handlers (same would occur with the tests); but I think the solution for this can be as easy to create more extensions and static classes/methods in an "Extensions" folder to contain all the shared code there.

Possible Implementation

To use it as an example, the current folder from Application.Features.Company could be structured like this:

  • Companies (folder)
    • Extensions (folder)
      • [ Any extra extension classes/files that can be used for sharing code between slices ]
    • CreateCompany.cs
      • CreateCompany (class)
        • Command (nested class)
        • Validator (nested class)
        • Handler (nested class)
    • EditCompany.cs
      • EditCompany (class)
        • Command (nested class)
        • Validator (nested class)
        • Handler (nested class)
    • DeleteCompany.cs
      • DeleteCompany (class)
        • Command (nested class)
        • Validator (nested class)
        • Handler (nested class)
    • GetCompaniesPage.cs
      • GetCompaniesPage (class)
        • Query (nested class)
        • Handler (nested class)
    • GetCompanyById
      • GetCompanyById (class)
        • Query (nested class)
        • Handler (nested class)

Each of the features (Create/Edit/Delete Company and Get Page/ById) would be separated into different files with a class that will nest 3/2 other classes (depending on whether it's a command or query), and each of these nested classes would be the specific command/query, its handler and (in the case of the commands) its validator.

@CesarD CesarD added the enhancement New feature or request label Dec 7, 2023
CesarD added a commit that referenced this issue Dec 13, 2023
## Description
Refactor the command and query classes such that each Command or Query
is a single class with subclasses that implement the required `Handler`
as well as any related `Validator` for `Commands`.

Unit tests have also been updated to reference the new Command and Query
structure.

## Related Issue
Implements and closes #57 

## Motivation and Context
## How Has This Been Tested?
## Screenshots (if appropriate):

## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.

---------

Co-authored-by: César <cesar.demicheli@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants