I've been tasked with speeding up a giant codebase. One of the things I have noticed is that the team uses lazy loading everywhere. So much so that I think there's a lot to be gained by disabling it. There would be too much of an impact if I disabled it entirely so I'd rather do this in phases.
This got me thinking: is there a way (an event?) to detect when EF is doing something lazily?
In case it matters, we're using EF6, but the context is based on ObjectContext instead of DbContext.
Due to the mess of the codebase it's not an option to just find references on the navigation properties.
I recommend you to use Glimpse, its a powerful tool for so many things, including EF profiler. You can see how the querys are been translated, and what time each query takes.
Related
What is the current status of linq2sql and is it sensible to use it still?
I am about to start a very large project and have quite a lot of experience with it.
However I don't want to avoid EF if that is really the way to go. I do like the simplicity of linq2sql.
In my opinion: no.
Why?
EF in v4 is just as easy to get started with as Linq-to-SQL
EF 4 also has options to do more complicated and advanced things - if you need to. No luck in Linq-to-SQL, really - it's simplicity is all there is - no advanced features
EF 4 has various approaches to building your system - Linq-to-SQL only has "database-first"
EF 4 allows you to update your model (if you're using the database-first approach) if your underlying database ever changes - is there any change it might?? No such luck with Linq-to-SQL - drop the table and drag it back on; tough luck if you modified table or column names, or added additional e.g. associations...
Linq-to-SQL was really more of a proof of concept to show off the capabilities of LINQ, developed by the C# language team. It was never really meant to be a full-fledged ORM. EF on the other hand was developed by the ADO.NET database team, and was intended to be a real enterprise-grade ORM / conceptual data model. Linq-to-SQL will not see any further development to speak of - maybe a bugfix here or there. EF on the other hand is Microsoft's strategic platform - they'll heavily invest in it and continue development here (see e.g. the "EF Migrations" to automagically update your database schema from within code).
My personal take: if you start new and you're on .NET 4 (or can go with it): go with EF v4. You can't go wrong, you have all the niceties of Linq-to-SQL - and then quite a few more, if you need them some time in the future....
Personally I'd try to make it such that the database layer is an implementation detail, behind a view-model, repository layer, and other such devices. Then the only question is:
does it work?
To which the answer will probably be "yes", but by abstrating that you can change it without much risk / re-work. Perhaps to the "fuller" ORMs (NH, EF, LLBLGen etc) - or perhaps the lighter micro-ORMs (dapper, simple.data, massive etc).
If L2S lets you get started quicky, there's no reason it can't be used. It might not be my first choice now, but it is a good tool, and I find it more intuitive than EF in many areas.
The key, though, is not painting yourself into a technological corner where change is too expensive.
Linq-2-SQL is dead... no matter you hear around
http://blogs.msdn.com/b/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
I would like to know what is the best method for developing a multi-user C# app using the SQL Server2005 as database. This is what I have in mind:
using nhibernate or telerik's openacces orm.
linq
using wrappers. all data from tables load into corresponding objects (at startup) and from that point only delete&update transactions affect the database.
...
I've looked at orm tools but in my opinion they generate a lot of code and i do not know if
it's necessary.
What is the best solution having in mind future changes in the application?
If i would choose the 3rd option how can i ensure that only one users modifies a row in a table(how can i lock a table row which is under modification) ?
Any suggestions or reading material will help!
Thanks!
There are hundreds of ways to solve this, but don't discount ORM. Microsoft's Entity Framework is getting better with every revision. The framework 4.0 bits are pretty good and play extremely well with LINQ.
As for generated code vs your own, try something like Entity Spaces... You have complete control over how the code gets generated and the data access layer is extremely powerful and flexible (not to mention very easy to use). It also plays nicely with LINQ.
I have written a lot of data access code over the years. In the beginning, the ORM tools were rough around the edges and left a lot to be desired. These tools have gone through many iterations since and have become indispensable in my opinion. I can't imagine writing routine after routine that does the same basic CRUD. I did that for years and spent lots of time correcting hardcoded SQL and vow to avoid it at all costs from here on out.
As for concurrency / locking issues, that's a question unto itself. There are many ways to provide locking (the major categories being optimistic and pessimistic). Each has its pros and cons.
If it's multiuser do NOT do #3. The purpose of an DBMS is to handle the multi-user aspects for you. Everything from transactions to access rights are built right in. Going down the path of mimicking that in your code will be difficult to get right. In the past some "engines" like Borland's BDE and MS Access did this. The end result is that you end up dealing with little things like data corruption and consistency errors.
Never mind that as your database grows the is going to take exponentially longer to start.
We typically stay away from ORM tools for a number of reasons, mostly feature / benefit / security concerns. Of course, we are extremely well versed in SQL and can take advantage of the specific features a given db server can offer, which most ORMs can't do. We also tend to tweak the queries based on performance metrics after product release, which would force a recompile of an app for most ORMs. By staying away from this, we can let production DBAs do their job. That may or may not be a concern of yours.
That said a lot of dev teams both like and successfully use the ones you spoke about. I would say to skip Linq-to-SQL in favor of Entity Framework if you're going that route. Linq-to-SQL has all but been replaced by EF.
Save yourself a load of effort and time and use an ORM. In terms of helping you decide which one, there is loads of information/opinion on the web (and StackOverflow!) about which one to use but that'll depend on what your application requirements are (which you haven't described).
I like Linq-to-SQL for small/mid sized apps. It's quick and easy and almost efficient. For bigger apps it'll depend on what types of data transformations and design you have in mind but Linq-to-Entities or nHibernate are probably the most appropriate.
Given that I'm very good with SQL and c#,
Should I learn another layer on top like NHibernate ?
Is NHibernate just a library (that stores in a Database)? Or it's a service?
Should I use NHibernate or ADO.NET Entity Framework?
If you think I should learn/use an ORM, give me your top reason.
You should use an ORM as long as you need to convert database data to and from business objects, since it will save you a lot of work and will allow you to focus on your application logic.
NHibernate is a .NET library that does just that, mapping .NET objects to database tables according to how you configure it. In this sense it is the same as the Entity Framework, only that EF is already embedded in the .NET framework and NHibernate is a separate assembly that you must reference in your project.
Last but not least, if you use SQL Server you should add LINQ to SQL to the list of possible ORM candidates, it is simpler that EF and for many scenarios it is more than appropriate.
It depends on your applications.
NHibernate is a library. So it's a DLL.
Depends on what you want. NHibernate is based on Hibernate which is battle tested.
It doesn't matter how good anyone is with SQL or C#. There is a fundamental gap with the tools when dealing with SQL and C#. Aside from all the other productivity boosts that I've had when I learned to Stop Worrying and Just Use an ORM, I found only having to deal with C# most of the time has helped greatly. I have far fewer impedance mismatches in my work now and I do believe that contributes to fewer bugs.
Less code you have to write is less code you have to maintain. ORMs allow you to worry less about certain details so you are free to concentrate on higher level tasks.
No, I tried Fluent NH and Castle Active Record and Spring Framework NH Extensions but they all obscure basic operations and make things less visible. Start using native NH, then add a layer after a year.
Yes, NH is a library, not a service. But the way you use it in your code makes it feel almost like a service (e.g. a data repository service)
I tried EF and found it nauseating so I would go with NH
For OLTP-like systems, ORM is the way of the future. Not using ORM for me is like not using unit-tests or programming in non-OOP language.
Probably, but it depends on what kind of applications you normally write.
NHibernate is primarily a DLL, but there is more to it than that.
NHibernate (Read this for more details: NHibernate, Entity Framework, active records or linq2sql)
My top reason would be so you can use Linq. Right now, you pretty much need an ORM to use Linq.
Unless it's a very small application, then the answer is 'yes'.
Library.
I hear people swear by the EF, but I'm very leery of it. I also don't like tying myself to all Microsoft technologies. NHibernate would be my suggestion.
First, you don't want to go through the time and headache of writing all the SQL and classes and such; it's just not worth it. Second, it allows for greater ability to switch from one RDBMS to another without having to change much code. Third, it'll give you more control in the future in terms of database abstraction and such.
I'm writing a WPF client app, using Linq to Sql with Sql Compact edition.
The db is relatively small (3MB) and read-only.
Bottom line is that The performance are not as good as I hoped them to be, and I'm looking for tips and practical ways to increase that.
More facts:
The schema contains around a dozen of entities with extensive relations between them.
Profiling the app found out that the query is being run quite fast but building the c# Entities is the the process that take the most time (could be up to 8 seconds).
Mostly I believe because we have used LoadWith, and the DataContext got no choice but to build the objects graph in memory.
I can provide additional information, if needed.
EDIT:
As I mentioned the db is read-only so DataContext is not tracking changes.
We are making use of static queries on reoccurring queries. The problem is when the application is initializing and we prefetch many objects to memory to be served as cache.
Thanks for your help.
Ariel
Well, you might find that making use of lazy loading (rather than eager loading) might help increase the performance (i.e. avoid using LoadWith) since the entities won't need memory allocated for the relationship chains (or deep loading of the object graph) and instead they will be populated on demand.
However, you'll need to be focused in your design to support this (otherwise you will simply move the performance bottleneck to become overly "chatty" with regard to SQL statements being executed against the SQL CE database.
The DataContext can also start to bloat (memory) as it tracks changes. You might need to consider your approach to how you use Data Contexts (for instance, you can attach them to new contexts provided the original context has been disposed).
A very simple solution is to use staticly declared compiled linq queries. This is of course not that practical, but it will improve performance as the expression trees will only need to be built once, during compile-time, instead of being dynamically created every time the query is called for execution.
This might help:
http://msmvps.com/blogs/omar/archive/2008/10/27/solving-common-problems-with-compiled-queries-in-linq-to-sql-for-high-demand-asp-net-websites.aspx
Few questions on ORM mappers like nhibernate (for .net/c# environment).
When queries are run against a sqlserver database, does it use parameter sizes internally?
paramaters.Add("#column1", SqlDataType.Int, 4)
Do they all use reflection at runtime? i.e. hand coding is always a tad faster?
does it support temp tables, table variables?
ORM World is powerfull and full featured one, I think today obstacles are peoples theirself, this to say that using ORM's needs to take changes in mind, in the way of thinkng applications, architectures and patterns.
To answer you questions:
Query execution depends on more factors, it's possible to fully customize the engine/environment to take advantages of various features like, deffered execution, future queries (queries executed in a future moment), multiple queries, and last but not least, session management involves in this area:
Deferred execution is based on concepts like lazy-loading and lazy execution, this means that queries are executed against the database just qhen you perform some actions, like accessing to methods of the NHibernate Session like ToList(), another example of deferred execution is with using of LinqToNhibernate, where just when you access to certain objects, queries are executed
Future queries are as I said beforre queries executed in a future moment, Ayende speaks well about that
Multiple queries are queries that can be "packed" together and executed in one time avoiding multiple roundtrips to the DB, and this could be a very cool feature
Session Management, this is another chapter to mention... but take in mind that if you manage well your session, or better, let NHibernate engine to manage well the session, sometime it's not needed to go to the DN to obtain data
in all the cases, tools like NHibernate generates queries for you, and parametrized queries are managed well with parameters even depending on the underlying DB engine and conseguently DB Dialect you choose!
It's clear that frameworks like NHibernate, most of the time, use reflection at runtime, but it's needed to mention the multiple Reflection optimization are used, see for example Dynamic Proxies... It's clear that somethime, or maybe all the time direct code could be faster, but just in the unit, in the big picture this could involve in more mistakes and bottlenecks
Talking about NHibernate, or better saying, It's usefull to understand what you mean when talk about Temp Tables and temp data.. In terms as are, NHibernate, as I know, doesn't support natively Temp Tables, in the sense of Runtime tables, but this could be done because NHibernate permit to create object mapping at runtime, so a mechanism of Temp data could be implemented using that api
I hope I provided an usefull answer!
...and oops, sorry for my bad english!
nhiberate uses an optimised form of reflection that creates proxy objects on startup that perform better than plain reflection, as it only incurs a one time cost. You have the option of disabling this feature as well which has nhibernate behave in a more typical manner, with the permanent use of reflection.
This feature is set with the following key:
<add key="hibernate.use_reflection_optimizer" value="true" />
Nhibernate can be used with variable table names. See this SO thread for a good solution.
NHibernate and SubSonic, LinqToSql, EF and I think most of the other ones use parameterized sql.
Most ORM's use some sort of reflection, there are some that generate all the code and SQL Query for you at design time so they don't have to use reflection code it might work a bit faster but it makes you domain a real mess and you have to use their application to regenerate all your code.
I am almost sure that they all don't support that but most have a way that you can use SP's and Views to do this.
You can check this out NHibernate Screencast Series http://www.summerofnhibernate.com/