So, there is a certain collection of interfaces. Each element in it is a different task releasing the ITask interface:

  public interface ITask { string Name { get; set; } string Type { get; set; } void Run(); void Edit(); void Save(); }

Each class that implements this interface has its own tasks and, accordingly, its own fields, its own customization views, etc., to summarize all this does not seem possible and reasonable. Around this concept was twisted logic and it worked until it was time to write the saving tasks in the database. And then it began, the whole curve of this scenario got into all the fields. I came to the concept - I will be serialized in JSON to the Base and that's it. So an idea, but did not invent anything better. The farther into the forest, the more appeared crutches and bicycles. As a result, the code turned into a hellish idle and difficult to debug mess. A few days I spit it so and so. Coming with a bow to you. Tell me, how do normal people solve such problems?

  • Well, without thinking, the first idea is that why not each type of task be serialized into a separate table for this type? Then it will be possible to remove the crutch with JSON. - VladD
  • Well, this thought came to me, but also not the most convenient thing - collect all this in one collection and then from a dozen tables. - Sergey
  • But a clean solution. If you have heterogeneous data, it is natural that they are stored in "heterogeneous" tables. Assembly into one collection directly reflects your subject area: heterogeneous tasks in the general collection. - VladD

1 answer 1

NHibernate allows you to map into one table the heirs of a single class without problems. At the same time the query on the collection works without joins.

As an example, different logins mapped into one table:

  public class LoginMap : ClassMap<Account.Login> { public LoginMap() { Not.LazyLoad(); Id(x => x.Id); Map(x => x.Name); Map(x => x.Password); DiscriminateSubClassesOnColumn("Type"); } } public class HentaichanLoginMap : SubclassMap<Manga.Hentaichan.HentaichanLogin> { public HentaichanLoginMap() { Not.LazyLoad(); Map(x => x.UserId); Map(x => x.PasswordHash); DiscriminatorValue(Manga.Hentaichan.HentaichanLogin.Type.ToString()); } } public class GroupleLoginMap : SubclassMap<Manga.Grouple.GroupleLogin> { public GroupleLoginMap() { Not.LazyLoad(); DiscriminatorValue(Manga.Grouple.GroupleLogin.Type.ToString()); } } public class AcomicsLoginMap : SubclassMap<Manga.Acomic.AcomicsLogin> { public AcomicsLoginMap() { Not.LazyLoad(); Map(x => x.PasswordHash); DiscriminatorValue(Manga.Acomic.AcomicsLogin.Type.ToString()); } }

Interface \ ancestor fields are mapped at the very top, the rest are supplemented for heirs, if necessary.

In a large project, it’s probably already inconvenient to write with your hands and you need to do some auto-generated mapping on templates.

  • one
    As a result, it turned out that Entity could also, rewrote into classes and everything fell into place. Thank! - Sergey