My project has a UI layer, a Service Layer and a Repository layer. The latter has Entity objects as part of the ORM (.net Entity Framework).
The service later returns a Dto to the UI layer.
My question is what object should the service layer work with? Should I return the Entities to my service layer methods for performing business logic calculations.
Take a look into "Clean Architecture" by Bob Martin: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
Just to summarize: your application's business rules must be testable without the database, the user interface, or any other external factor. Therefore, if your Entities expose stuff related to database, then perhaps your design could be improved.
My question is what object should the service layer work with? Should I return the Entities to my service layer methods for performing business logic calculations.
If your Entities are part of Repository layer, then they shouldn't be returned by your application (which is represented by your Services layer). Your application must work as one unit, and be testable too. So, define appropriate objects to be declared within Services layer and return them to whatever client might be using your app.
Follow the "Functional Core, Imperative Shell" model. This is the essence of all modern architecture including Uncle Bob's "Clean", the Onion architecture as well as things like the Elm architecture.
According to this model your service layer, the core of your app, will have all the logic of your app but none of the side effects. This will make your service layer very easy to test, no stubs, mocks or test doubles needed.
If your Entity objects can be built independent of the ORM, then it's fine to use them in your service layer, otherwise you will have to create some "Plain Old Data" types to pass into the service layer.
Some resources:
