I would suggest that a lot of your questions and the surrounding context would be answered in more detail by looking up guidelines on the specific architecture you're working with.
For the purpose of this question, I'm only going to address your concrete questions, and avoid doing the entire architecture spiel.
If we ignore this issue and use the entities in the presentation layer anyway, how can they be augmented or adjusted for evolving requirements in the presentation layer without affecting code in the persistence layer?
I assume that by "entity", you are referring to a class that is an identical representation of your persistence format (e.g. table structure).
On that assumption the direct answer is that you can't. You won't have encapsulated your entities within your persistence layer, since the entities are being exposed publicly, to be used and referenced by the consumers of the persistence layer.
Is that a problem? Well, personally I don't like it. I would always introduce a mapping conversion between the internal entity and the exposed data model.
How can the presentation layer invoke a DAO without revealing how entities in the persistence layer are defined?
For n-tier architecture, the general solution is that each layer should provide a mapping abstraction on its internal components so as not to expose them to the outside world. Even if the internal component is identical to its mapped counterpart, I would advise you already create this layer so as to avoid tight coupling and a potentially difficult refactor if these two models ever do diverge.
However, I also tend to work with more domain-oriented architectures that rely on inverted dependencies, where the persistence layers' public interface is not defined by the persistence layer itself. This makes it patently impossible for the interface to expose the entity, since the interface definition does not even have access to the entity's definition in the first place.
But that's more a matter of working with a different architecture than the n-tier architecture you're working with right now, so that might not be a relevant answer here.
Does the use of a DAO imply a service that sits above it in the persistence layer and handles requests from the presentation layer?
Your answer is asking if that's a universal given. The answer to that is no. But is it generally a good idea? I would say yes in most scenarios, and as a default unless you have a good justification to not do so.
"Service" is a vague term. I assume you're referring to a repository here (or something that fills the same role). This repository can act as the mapping point, therefore its public interface can rely on using the mapped DTOs instead of the entities itself.
Effectively, you would see the entity models being used inside the repo method bodies, but the repo method signatures would be using the DTOs instead. Rouch example:
public void Create(PersonDto personDto)
{
var personEntity = mapper.Map(personDto);
// Create logic, using personEntity
}
public PersonDto GetById(Guid id)
{
var personEntity = ...; // Fetch logic, using personEntity
var personDto = mapper.Map(personEntity);
return personDto;
}
This is a really simple example, highlighting that the first (for input models) and last (for output models) lines of your method body would convert the data to/from the entity model, so that the rest of the method can be centered around the entity model without exposing that entity to the outside world.
