none
Using both Enterprise library and Entity framework as DAL for same application RRS feed

  • Question

  • We have been using EF for large amount of data  retrieval in our current application. We faced performance related issues with using EF with large data retrieval and manipulation.

    We need to extend the same project with some additional functionality similar to what currently exists in the application and uses EF.

    For the new functionality, we do not want to use EF and want to use enterprise library for Data access.

    My question is if we use both entity framework for parts of the application data access mechanism and enterprise library for other parts of application data access, are there any known issues?

    if there are any best practices to be followed please share .


    • Edited by MituD Saturday, February 14, 2015 10:52 PM
    Saturday, February 14, 2015 2:52 PM

Answers

  • I cannot pull out EF layer from the application right now, however going forward I will abstain from using EF and will use stored procs .

    Apparently, you are using an ORM in a manner and in a situation that it shouldn't have been used in concerning huge amounts of data in data processing. And now you are going to left field about an ORM talking about those bunny rabbit breeding sprocs. EF is using the internal MS SQL Server Stored Procedure to submit the generated T-SQL with all the benefits of using a sproc that you created yourself. So I don't see the point if you running to sprocs you make. 

    An ORM is more geared towards client/server and SOA applications where one doesn't send huge amounts of data over the wire and the lifetime of the application doing the data processing is very short, which are typical client/server Web and SOA applications or distributed applications. An ORM works very well in those situations.

    I hope this is concerning this one application you not using an ORM, because otherwise, it may be a mistake by you. I have a feeling you are going to run back to datasets and datatables, which are pretty bad concerning speed due to the unboxing that occurs. :)

    any suggestions on that?

    Yeah, you can use Entlib and EF together why not in a Data Access Layer. 

    BUT!

    https://msdn.microsoft.com/en-us/magazine/cc163766.aspx

    <copied>

     The Enterprise Library DAAB contains a lot of code, but if you are not going to need database abstraction and your application is small in scale, you might not want to use it. You might want to consider using ADO.NET directly if you have an application that is not tiered or does not warrant a true DAL

    <end>

    Myself, I wouldn't use Entlib and would just use straight up ADO.NET, SQL Command objects, T-SQL in-line or a sproc and with a datareader. I would be using generics, like collections and not datasets and datatables.

    FYI

    https://msdn.microsoft.com/en-us/data/hh949853.aspx

    https://msdn.microsoft.com/en-us/library/vstudio/cc853327(v=vs.100).aspx

    Sunday, February 15, 2015 1:11 AM

All replies

  • We have been using EF for large dataset retrieval in our current application. We faced performance related issues with using EF for large data set's  .

    Dataset? What are you talking about?  If you are using the salad bowl, the dataset with datatables, then here is the reason not to use them.

    http://lauteikkehn.blogspot.com/2012/03/datatable-vs-list.html

    My question is if we use both entity framework for parts of the application data access mechanism and enterprise library for other parts of application data access, are there any known issues?

    What is Entlib going to buy you in performance? It's going to buy you nothing. You'll be better of going to the EF backdoor, use SQL command objects, inline T-SQL, sprocs, datareder and using custom objects or objects off of the virtual model returning a single object or objects in a collction., if you are concerned about performance.

    http://blogs.msdn.com/b/alexj/archive/2009/11/07/tip-41-how-to-execute-t-sql-directly-against-the-database.aspx

    You'll probably be better of going to Entity SQL, using a datareader, collection and using custom objects or objects off of the model, if you are concerned about query performance.

    https://msdn.microsoft.com/en-us/library/vstudio/bb738684(v=vs.100).aspx

    https://msdn.microsoft.com/en-us/library/vstudio/bb387145(v=vs.100).aspx

    https://msdn.microsoft.com/en-us/library/vstudio/bb399560(v=vs.100).aspx

    My question is if we use both entity framework for parts of the application data access mechanism and enterprise library for other parts of application data access, are there any known issues?

     A nightmare, no consistency and complete Helter Skelter is what I see. Been there and seen it in action with different technologies doing the same thing in a solution.

    Saturday, February 14, 2015 5:11 PM
  • I will be using Sprocs and SQL bulk copy for most purposes however want to use enterprise library as a data access application layer for stored procedure call's.

    I cannot pull out EF layer from the application right now, however going forward I will abstain from using EF and will use stored procs .

    any suggestions on that?

    Saturday, February 14, 2015 10:37 PM
  • I cannot pull out EF layer from the application right now, however going forward I will abstain from using EF and will use stored procs .

    Apparently, you are using an ORM in a manner and in a situation that it shouldn't have been used in concerning huge amounts of data in data processing. And now you are going to left field about an ORM talking about those bunny rabbit breeding sprocs. EF is using the internal MS SQL Server Stored Procedure to submit the generated T-SQL with all the benefits of using a sproc that you created yourself. So I don't see the point if you running to sprocs you make. 

    An ORM is more geared towards client/server and SOA applications where one doesn't send huge amounts of data over the wire and the lifetime of the application doing the data processing is very short, which are typical client/server Web and SOA applications or distributed applications. An ORM works very well in those situations.

    I hope this is concerning this one application you not using an ORM, because otherwise, it may be a mistake by you. I have a feeling you are going to run back to datasets and datatables, which are pretty bad concerning speed due to the unboxing that occurs. :)

    any suggestions on that?

    Yeah, you can use Entlib and EF together why not in a Data Access Layer. 

    BUT!

    https://msdn.microsoft.com/en-us/magazine/cc163766.aspx

    <copied>

     The Enterprise Library DAAB contains a lot of code, but if you are not going to need database abstraction and your application is small in scale, you might not want to use it. You might want to consider using ADO.NET directly if you have an application that is not tiered or does not warrant a true DAL

    <end>

    Myself, I wouldn't use Entlib and would just use straight up ADO.NET, SQL Command objects, T-SQL in-line or a sproc and with a datareader. I would be using generics, like collections and not datasets and datatables.

    FYI

    https://msdn.microsoft.com/en-us/data/hh949853.aspx

    https://msdn.microsoft.com/en-us/library/vstudio/cc853327(v=vs.100).aspx

    Sunday, February 15, 2015 1:11 AM