CODEWITHSUNDEEP
c#entity-framework.net-coreef-database-firstef-core-2.1
Ish Thomas
Ish Thomas

Reputation: 2440

EF Core - not needed attributes in DB First approach

If the client uses EFCore DB-first approach, to connect to the database, but will never do any migrations (only simple CRUD operations) is TypeName (in `Column attribute) parameter even necessary?

If TypeName is not provided, the client should use the type declared in the class and the db should use the type declared while creating the table. If the client will never perform any migrations is it a right thing to ignore that attribute and not specify it at all? Although "Column" attribute is a must, because the column name in the db is not always the same as in C# entity, but Type is not necessary. Is that correct?

My second question is, are there any guidelines for apps that will connect to already existing db without migrations? A list of attributes that are simply not needed in case of db-first/no-migrations approach?

EDIT:

Additional attributes, that I'm not sure are necessary (in fluent API as well), are:

entity.HasIndex(e => e.Name);
entity.HasIndex(e => e.BankId).HasName("_dta_index_item_1_070970510");
entity.Property(e => e.Foo).IsUnicode(false);
entity.Property(e => e.Bar).HasDefaultValueSql("(getdate())");

I'd like to generate my Models and DbContext from existing db, but without stuff necessary only for migrations. I need to read and write to the db only, so I would assume, proper names, types and relationships only.. I think, I'm not sure.

Upvotes: 1

Views: 968

Answers (2)

RAHUL S R
RAHUL S R

Reputation: 1579

as Steve explained as per your 1st confusion
for your second question you can use ef cores db scaffolding

Scaffold-DbContext "Your Connection String" Microsoft.EntityFrameworkCore.SqlServer -OutputDir YourModelFolder

Upvotes: 0

Steve Py
Steve Py

Reputation: 34683

The various attributes are not just for migrations, but can help EF determine how to compose/cast values during operations. One example would be for enumerations. They can be stored as Integers or Strings. Things like HasDefaultValueSql("(getdate())"); isn't needed if the database is already set up for default. Column types for Db First will default based on their time. If you're using Code-First you will want to tell EF how big a string column should be, and whether it should store Unicode or ASCII, but for Db First it just cares that the two data types are compatible. (C# object & database)

That said, most properties on the entity don't need any attributes. EF can infer them and ensure they are compatible. The only attributes I use somewhat regularly in the entity are Property Name for cases where I want a more descriptive name in my entity, and property type in the few cases I need explicit casting. For PKs you will want to leverage DatabaseGeneratedOption for Identity (or defaulting) columns. I use [TableName] where my tables may not follow EF's default naming convention expectations. Basically I default to adding no explicit column configuration at all (other than for the PK and navigation properties), then add only what is needed. I've seen a few projects that used Db First where every property in every entity is mapped out. IMO it may be thorough, but a bit excessive.

Attributes or config won't hurt. About the only thing you need to worry about ensuring EF doesn't perform a migration or attempt to initialize a DB. With EF6 you had to explicitly turn this off via Database.SetInitializer<TDbContext>(null); At least with EF Core you don't need to worry about it since you have to explicitly call it.

Upvotes: 1

Related Questions