I am trying to replace my existing database access layer with an Entity Framework implementation in a Web API project. I already have some domain classes containing the logic and properties required, for example Airport1, but Entity Framework generated duplicate objects, for example Airport2. Do I need to merge Airport1 into the Airport2 object created by EF? Or just change my Airport1 class to a partial class??
One of the powers, and sometimes the flaws, of EF is that it's designed to keep one half of the database/model relationship in sync with the other, so that you don't have to. There are two basic models for this; database-first and code-first. In database-first, EF examines a pre-existing database schema and generates a domain model matching its references. In code-first, EF examines your domain and generates "migrations" which produce and update a database schema.
What you seem to want to do is combine these approaches; generate a class for most objects, but use your own definition of the "Airport" object overriding the generated model. Unfortunately there isn't a ridiculously-convenient way to do this, which is job security for us.
Your options are:
Discard your existing model and generate a new one using the "database-first" paradigm. You'll lose any custom business logic from your existing domain that isn't inherent in maintaining basic database integrity; this logic will have to be moved up to a different layer, such as your controller/presentation layer.
Discard your existing database and use Code First Migrations to generate a new one based on default conventions. You'll have to use SSIS, the SSMS Data Import tool or manual Insert-Select statements to get the data from your old DB into your new one.
Map your existing model to your existing database in the Code First paradigm with custom Entity Type Configuration mappings and mapping conventions. You will lose a lot of EF's power to handle this boilerplate for you, but will be able to keep your existing domain model and have practically total control over how your domain model translates to your data layer.
Edit the mapping template files of the database-first paradigm to include custom business logic in generated classes. This solution gets very unwieldy very quickly, but will do the job for a few must-have additions to otherwise POCO domain classes.
Edit the database-first mapping templates to generate partial domain classes, which will pair with developer-coded partial declarations containing custom business logic. Allows for inclusion of business logic functions in the domain without a lot of cruft in the template, but it has its own limits; for instance you can only add functions and non-mapped properties this way, you can't create custom properties that will be mapped to the DB (while you can create a custom property to "wrap" a mapped one, this would create a very confusing model relying on coder conventions to determine which property to use from consuming code).