When writing a DAL in a .NET application, it was decided to use the CodeFirst approach of EF6. There is an entity class - client:

public class Client { public int ClientId { get; set; } //PK //... //address properties: public string City { get; set; } public string Street { get; set; } public string House { get; set; } public string Flat { get; set; } //... }

From the point of view of the OO approach, it makes sense to encapsulate the properties related to the address of the object in a separate class for the convenience of accessing the object itself in the code, then the code will look like this:

 public class Client { public int ClientId { get; set; } //PK //... public int AddressId { get; set; } public Address Address { get; set; } //... } public class Address { public int AddressId { get; set; } //PK public string City { get; set; } public string Street { get; set; } public string House { get; set; } public string Flat { get; set; } }

And everything seems to be fine, but you need to store in the database itself the fields with the address value as regular columns for each client in the table containing the client data, and not allocate a separate table for the addresses. But at the same time, in the code itself I would like to encapsulate the fields in a separate class. Can this be done with Fluent API or DA? And is it even possible? Thank.

  • > you need to store in the database itself the fields with the address value as normal columns for each client in the table containing the client data, and not select a separate table for the addresses. Who needs it? Addresses will be used in other zamaplennyh entities? If yes, then you all need a separate label. - Monk
  • What is the reason for the need? I would, apart from the fact that Address stored separately, I would still break it on City , Street i.e. separate directories and otherwise get ready to overcome the difficulties that you are laying yourself. and what you want is possible, but better do it right - Bald

3 answers 3

It is enough just not to allocate the address in a separate entity. View Model:

 public class Client { [Key] public int ClientId { get; set; } public Address Address { get; set; } } public class Address { public string City { get; set; } public string Street { get; set; } public string House { get; set; } public string Flat { get; set; } }

in context

 public class Model1 : DbContext { public Model1() : base("name=Model1") { } public DbSet<Client> Clients { get; set; } }

will generate one table:

 CREATE TABLE [dbo].[Clients]( [ClientId] [int] IDENTITY(1,1) NOT NULL, [Address_City] [nvarchar](max) NULL, [Address_Street] [nvarchar](max) NULL, [Address_House] [nvarchar](max) NULL, [Address_Flat] [nvarchar](max) NULL, CONSTRAINT [PK_dbo.Clients] PRIMARY KEY CLUSTERED ( [ClientId] ASC ) )

    In the first approximation, the simplest way is to inherit the client from the address ... Although from the point of view of philistine logic, this is odd:

     public class Address { public String Street { get; set; } /// ... } public class Customer : Address { public int CustomerId { get; set; } /// ... }

    Well and addresses thus naturally will not be separately stored, and it will not be necessary to refer to them a foreign key.

      you need to store in the database itself the fields with the address value as normal columns for each client in the table containing the client data, and not allocate a separate table for the addresses. But at the same time, in the code itself I would like to encapsulate the fields in a separate class.

      Inheritance with EF Code First:

      • Table per Hierarchy (TPH)
      • Table per Type (TPT)
      • Table per Concrete class (TPC)

      examples and explanations here .