Fluent API Modulated System

Question

Good afternoon! I am developing a modular system. Where in this system I have the registration module, the sales module, financial ... The structure of my project is like this. I have a solution, in it I have the main project where will be menu screen, system opening ... then I have a project called cadatros, and a project called sales (each module is a project). Good, I would like that when I run the system, if the customer does not have the sales module, it does not create the sales tables in the database (I am developing the base with date Annotation and Fluent API - CF). Well I came across the following dilemma: In the sales module I have the requested table, which will have a relationship with client that is in the registration module (References to access guidelines of other modules is OK) The doubt is .. How do I create this relationship? is a relationship 1.. No customer model has public virtual ICollection<Pedido> pedidos {get;set;}, would only have in Request public virtual Cliente cliente {get; private set;}

Answer 1

Well, after a lot of research I found two Alternatives. In case someone knows a better one, it would be nice to post, but I will give this post as solved.

The first alternative is to create the database Schemas without relationship between the tables, make these relationships directly via code (I do not like to use this practice because if you pass an encoding unnoticed in the fields for relationship, such as sending an Id not existing in the mother table, the daughter table accept the record even so, without a direct control of the bank ...). Then they would be totally different parts of the first tables.

The second way would be to import the table again and in Dbcontext create the "public virtual Dbset .... where the class representing the mother table would only be a copy of the other class, there would create a problem, would always have to be changing the two classes in the case of one undergoing change.... In this case I have chosen the first alternative that I thought was a best practice in this context.