It depends on the layering of your application, and if you think your application requires a business layer which is not tied to a specific ORM technology, or if you think such a layer separation is not necessary.
Usually, you decide to have either one layer, where your "business objects" are directly mapped to database tables and contain certain business logic (like a method
GetFullName). This is probably sufficient for smaller applications with only a few tables, a few business classes, and not many structural differences between them.
Or, you decide to have two layers, with a full separation between a class
PersonDTO which is used for the EF code-first approach of persistence, and a business class
Person, which is independent from EF, but holds the business logic. In this case,
Person will get a method like
GetFullName and providing the same logic in
PersonDTO would duplicate it, which is actually what you asked us how to avoid.
I guess it is clear this is a trade-off - the former approach requires less code, but every code which uses your business objects now requires to have dependency on EF as well, and it imposes certain restrictions on how your business classes will have to look like. The latter requires extra code for mapping between
Person (this is where tools like Automapper show their value).
So I recommend you first look what kind of application you are going to write, and if you think the layer separation between DTOs and a business layer makes sense or not. Then you know where to place the methods.