payroll-case-study | learning Uncle Bob 's payroll case study | Machine Learning library
kandi X-RAY | payroll-case-study Summary
kandi X-RAY | payroll-case-study Summary
This is my learning journey of the Payroll Case Study from the book "Agile Software Development principles patterns and practices" by Robert C. Martin (a.k.a. Uncle Bob). It is written in Java, using JUnit and Hamcrest for testing, Maven for dependency management.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Changes the Compensation of the Employee
- Sets the payment schedule
- Sets the payment classification
- Execute the payment for a recipient
- Get the payment classification
- Add a new sales receipt record
- Create an Employee
- Add an Employee instance
- Executes the payment for a person
- Add a time card
- Calculates total pay
- Change the Employee
- Deletes the Employee
- Updates the member of the Employee
- Record membership
- Assign data to pay
- Determine if the given date is a pay date
- Changes the member s membership
- Sets the postal address
- Calculates the total pay for a TimeCard
- Gets the pay period
- Verify pay date
- Get the first - of - period start date
- Executes the union member
- Get the Monday start date
- Is pay date
payroll-case-study Key Features
payroll-case-study Examples and Code Snippets
Community Discussions
Trending Discussions on payroll-case-study
QUESTION
Context:
Uncle Bob has an example called the payroll example. This page has a great downloadable example and walkthrough of what this is exactly: http://cleancodejava.com/uncle-bob-payroll-case-study-full-implementation/#disqus_thread.
In the payroll example, an employee has 4 classes that represent pay schedule/pay type/etc.. (which could be from 20 different tables theoretically). There are various "interactors" that interact with each of these classes. The interactors use a gateway to access the employee via findById() which returns a loaded employee with all 4 classes also retrieved from the database.
Question:
This is great in example but in a larger system I run into some questions around entity fetching.
A new use case comes up where we just want to edit the employees name. Using the gateway findById returns an employee (great!) but also does a bunch of unnecessary loading of the 4 extra classes that are unnecessary to the updateEmployeeName interactor.
So:
- Do we partially load the employee based on the use case? This means the gateway may have many many more highly specialized loading methods.
- Do we load an entirely new type of stripped down employee? (NamableEmployee) This would mean a lot of entities that all just meet specific use cases.
- Does the entity "lazy load" other fields as necessary? This means the entity would need a gateway to access its sub fields that are in other tables.
- Any other ideas on how this may work?
Or did I just misunderstand what entity means entirely? Is this the reason why in this architecture the employee is abstract? So the gateway can return stripped down versions that still "appear" as an employee?
Thanks a bunch!
...ANSWER
Answered 2022-Jan-06 at 07:05Using the gateway findById returns an employee (great!) but also does a bunch of unnecessary loading of the 4 extra classes that are unnecessary
It seems that you are mixing database entities with entities. The entities in the clean architecture are not database entities. You should not have any database details in these entities. This even includes annotations like some frameworks use, e.g. @Entity(table="employee")
Separate the business entity from the database entity. If you do you can decoupled the entities from how they are persisted. In some cases you might use plain sql and in other cases you use a ORM framework. But if you decouple them you can design the database entities according to the persistene needs and the business entities according to business needs. This is also an application of the single responsibility principle since the two change for different reasons.
Do we partially load the employee based on the use case? This means the gateway may have many many more highly specialized loading methods.
Yes you do. But you can also introduce an entity for that type of usage. E.g. an EmployeeUpdate that only has the properties that can be updated.
Does the entity "lazy load" other fields as necessary? This means the entity would need a gateway to access its sub fields that are in other tables.
The entity should never load any fields. If it does it is not a business entity it's a database entity provided by some kind of ORM framework. You should separate them as I explained above.
Any other ideas on how this may work?
When we load a complete entity to just update a single property we often think about efficiency and performance. But we should also think about the use case itself. Is it executed a lot of times or is it a use case that is only executed a few times. Is the effort to provide an performance optimized rename method worth it or should we just load the whole data?
Finally I would create a repository that returns an EmployeeUpdate. E.g.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install payroll-case-study
You can use payroll-case-study like any standard Java library. Please include the the jar files in your classpath. You can also use any IDE and you can run and debug the payroll-case-study component as you would do with any other Java program. Best practice is to use a build tool that supports dependency management such as Maven or Gradle. For Maven installation, please refer maven.apache.org. For Gradle installation, please refer gradle.org .
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page
