Skip to content
This repository has been archived by the owner on Aug 21, 2024. It is now read-only.

Convert Employee Commands to CSharpFunctionalExtensions #141

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

KyleMcMaster
Copy link
Owner

@KyleMcMaster KyleMcMaster commented Sep 10, 2023

Description

  • Adds foundation for migrating to CSharpFunctionalExtensions feature by feature rather than an all or nothing "big bang" approach by using the Strangler Fig pattern.
  • Migrates Employee Commands to CSharpFunctionalExtensions
  • Updates packages exception for Microsoft.* packages
  • Other minor fixes

Purpose

  • Feature
  • Partial Feature
  • Bugfix
  • Docs, Config
  • Chore / Format

Change Type

  • Major
  • Minor
  • Fix

Data Persistence Changes

N/A

Configuration Changes

N/A

@@ -2,6 +2,7 @@
<PropertyGroup>
<LangVersion>latest</LangVersion>
<Nullable>enable</Nullable>
<WarningsAsErrors>CS8600;CS8602;CS8603</WarningsAsErrors>
<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍👍

namespace PayrollProcessor.Core.Domain.Intrastructure.Operations.Commands;

/// <summary>
/// TODO: Temporarily named after the Strangler Fig Pattern as this serves as an implementation of <see cref="ICommandDispatcher"/> migrating to CSharpFunctionalExtensions from LanguageExt.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you done this kind of naming in a project before? I haven't but I like the idea of calling this type out explicitly. That way, you know it should eventually be renamed when it takes over.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't done this before but the approach was mentioned in Code That Fits In Your Head and I couldn't think of a better name so I figured calling it out explicitly would be best while the code is in migration state.

@@ -34,7 +35,7 @@ public EmployeeCreate(ICommandDispatcher dispatcher, IEntityIdGenerator generato
OperationId = "Employees.Create",
Tags = new[] { "Employees" })
]
public override Task<ActionResult<Employee>> HandleAsync([FromBody] EmployeeCreateRequest request, CancellationToken token)
public override ActionResult<Employee> Handle([FromBody] EmployeeCreateRequest request)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you drop the Async suffix most of the time now? I think Microsoft s current guidance is to only use it if there is also an existing sync API of the same name...

But I've seen a lot of modern code go both ways.

@KyleMcMaster KyleMcMaster marked this pull request as draft March 29, 2024 01:09
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants