none
Can I prevent EF from validating my database schema during startup? RRS feed

  • Question

  • I'm concerned with the startup times of EF, especially with our database, which has more than 1500 tables.

    I would like to handle schema changes manually using the EF migrations system, and I would like EF to not validate the database schema during startup. This would speed up startup. Is this possible at all?

    I know I can do this with DevExpress XPO, by passing AutoCreateOption.SchemaAlreadyExists when creating the DAL. But I would like to use EF because of other reasons. But this is a major turn-off.

    Thanks,
    George

    Thursday, October 10, 2013 7:57 PM

Answers

  • <copied>

    I'm using EF  6.0.

    <end>

    You are looking for a game plan? There is no game plan, and one needs to have seen it being down on other solutions that were using N-Tier where no ORM is being used, or an object code generator was being used in place of an ORM.

    The key is this.

    1) Using DTO(s) Data Transfer Objects which is an abstraction layer away from the ORM objects.

    2) Using a Business Logic Layer that calls methods on the DAL for a single entity on the model for CRUD using DTO(s).  

    3) Using a Data Access Layer that does CRUD operations for a single entity on the model using DTO(s).

    With the Model First Approach, you can now expose the primary and foreign key properties on the entities. This gives you complete control of CRUD operations for a given entity on the model.   

    You should point the generator to the model and build the DTO(s) 

    http://visualstudiogallery.msdn.microsoft.com/655aa6d4-4461-42ea-aeec-64cdb1313de7

    You should create a classlib project call it "Entities" where you will place all the DTO(s) so that any project can set reference to it and use the DTO(s). DTO(s) are used to pass data from a database through the subsystems or layers.

    http://en.wikipedia.org/wiki/Data_transfer_object

    Of course you would need logic to map and entity to a DTO and DTO to entity. There are lots of articles out Bing and Google on this.

    http://msdn.microsoft.com/en-us/magazine/ee321569.aspx

    You have to start segregating the model, which means you will have more than one model being used in a given project.  You'll have to start deleting associations off of the model when you know that an entity has an association to a entity sitting on another model, but you see you can so that, because the DTO(s) are built upon the properties (primary and foreign key properties) seen in the entities, which gives you all the information needed to map the DTO back to an entity and persist the entity to the database.

    The BLL logic has to know how many different DTO(s) need to be built and sent back to the client. The BLL for a parent will have to make calls to other BLL logic to get other DTO(s) built, or it can make direct calls to the DAL for children  building child DTO(s) to return

    This also applies the DTO(s) being persisted and knows what other BLL it needs to call passing DTO(s) for persistence,  or it makes direct calls to the DAL to persist parent and children DTO(s).

    All the logic of the BLL and DAL has to know how to work with multiple models, and they need to be able to go across models as needed.

    There is know game plan for this, and one has had to seen it in action.

    If deleting associations off of the model, you have to go to to the EDMX and delete the  associations tags for an entity out of the EDMX. 

    Note: That if you delete the associations and update the model, like adding a new table, the EF are going to put the associations back  line and all. You'll have to delete them again.

    I suggest to do a small testing situation and see what you have to do and put into place to make it happen.

    Wednesday, October 16, 2013 11:43 AM

All replies

  • <copied>

    But this is a major turn-off.

    <end>

    This wouldn't be a concern, if you were using the EF Model First approach.

    Thursday, October 10, 2013 11:41 PM
  • I don't think model-first is a good option for a database with more than 1500 tables. Do you?
    Friday, October 11, 2013 2:00 PM
  • <copied>

    I don't think model-first is a good option for a database with more than 1500 tables. Do you?

    <end>

    Where does it say that 1,500 tables have to be on one model? Where does it say that a DAL can't have more than one model in the project?

    So what you are talking about makes no sense.

    Friday, October 11, 2013 2:07 PM
  • They don't all have to be in the same model, but those that are related have to be, and in our case, that's too much for a single model.
    Friday, October 11, 2013 2:49 PM
  • <copied>

    They don't all have to be in the same model, but those that are related have to be, and in our case, that's too much for a single model.

    <end>

    No they don't have to be on the same model in a relationship.  Entities on the model can have their primary and foreign-key properties exposed in the entities. This kind of tells me that you don't know how to use Data Transfer Objects, and you don't know how to use a BLL and DAL logic effectively with n-tier.

    This was being done with custom objects,  SQL command object with T-SQL and datareaders  for CRUD operations with a database with relations honored too well before .EF hit scene.

    Just because you have not done it or know how to do it, doesn't mean it can't be done. And it can be done with the model too. :)

    Friday, October 11, 2013 3:05 PM
  • Would you be kind enough to point me to a resource that shows how to do this? Thanks.
    Friday, October 11, 2013 7:44 PM
  • What version of EF are using Framework 3.5, 4.0 or what?

    Would you be kind enough to point me to a resource that shows how to do this? Thanks.

    Friday, October 11, 2013 8:37 PM
  • I'm using EF  6.0.
    Monday, October 14, 2013 1:32 PM
  • <copied>

    I'm using EF  6.0.

    <end>

    You are looking for a game plan? There is no game plan, and one needs to have seen it being down on other solutions that were using N-Tier where no ORM is being used, or an object code generator was being used in place of an ORM.

    The key is this.

    1) Using DTO(s) Data Transfer Objects which is an abstraction layer away from the ORM objects.

    2) Using a Business Logic Layer that calls methods on the DAL for a single entity on the model for CRUD using DTO(s).  

    3) Using a Data Access Layer that does CRUD operations for a single entity on the model using DTO(s).

    With the Model First Approach, you can now expose the primary and foreign key properties on the entities. This gives you complete control of CRUD operations for a given entity on the model.   

    You should point the generator to the model and build the DTO(s) 

    http://visualstudiogallery.msdn.microsoft.com/655aa6d4-4461-42ea-aeec-64cdb1313de7

    You should create a classlib project call it "Entities" where you will place all the DTO(s) so that any project can set reference to it and use the DTO(s). DTO(s) are used to pass data from a database through the subsystems or layers.

    http://en.wikipedia.org/wiki/Data_transfer_object

    Of course you would need logic to map and entity to a DTO and DTO to entity. There are lots of articles out Bing and Google on this.

    http://msdn.microsoft.com/en-us/magazine/ee321569.aspx

    You have to start segregating the model, which means you will have more than one model being used in a given project.  You'll have to start deleting associations off of the model when you know that an entity has an association to a entity sitting on another model, but you see you can so that, because the DTO(s) are built upon the properties (primary and foreign key properties) seen in the entities, which gives you all the information needed to map the DTO back to an entity and persist the entity to the database.

    The BLL logic has to know how many different DTO(s) need to be built and sent back to the client. The BLL for a parent will have to make calls to other BLL logic to get other DTO(s) built, or it can make direct calls to the DAL for children  building child DTO(s) to return

    This also applies the DTO(s) being persisted and knows what other BLL it needs to call passing DTO(s) for persistence,  or it makes direct calls to the DAL to persist parent and children DTO(s).

    All the logic of the BLL and DAL has to know how to work with multiple models, and they need to be able to go across models as needed.

    There is know game plan for this, and one has had to seen it in action.

    If deleting associations off of the model, you have to go to to the EDMX and delete the  associations tags for an entity out of the EDMX. 

    Note: That if you delete the associations and update the model, like adding a new table, the EF are going to put the associations back  line and all. You'll have to delete them again.

    I suggest to do a small testing situation and see what you have to do and put into place to make it happen.

    Wednesday, October 16, 2013 11:43 AM