Is using CRUD stored procedures against a view with NOLOCK bad?

Our DBAs have created a pattern where our database layer is exposed to EF via views and CRUD stored procedures. The CRUD works against the view. All the views have the NOLOCK hint. From what I understand, NOLOCK is a dirty read, and that makes me nervous. Our databases are not high volume, but it seems like blanket NOLOCK is not very scalable while maintaining data integrity. I get that the decoupling is a good idea, 开发者_StackOverflow中文版but the problem there is we don't. Our externally exposed objects look just like our views which map 1 to 1 with our tables.

"If we want to change the underlying data model, we can." ... but we don't. I won't touch on what a PITA this all is from a VS/EF tooling viewpoint.

Is NOLOCK used in this situation bad? Since our database looks exactly like our class library, I think it makes sense to just get rid of the whole view/sproc layer and hit the DB direct from EF, does it?

Issuing a nolock is absolutely a dirty read. There are times that there is no impact from this, but in some scenarios you may have result sets with missing records or duplicates Itzik Ben-Gan has some Q&A regarding this topic. The reason for using stored procs to abstract your CRUD operations are pretty obvious when you want to do some storage optimizations after the project goes into maintenance mode. Think of the views as a way for you to not need to worry about that later. It can be easier for your DBA's to optimize the data access code as well without consuming your time as a developer. I cannot say that your DBA's are right or wrong based only on the data in this post. There are simply too many variables that may go into the decision. A blanket implementation of nolock being the correct option would be rare though. HTH

bob beauchemin blog has many good articles about gauging the strengths and weakness of ORM wrappers from an expert DB designer perspecive. Good to check out to learn wtf is actually going on when you use EF. Regarding using NOLOCK hint this will be good until it isn't ! As you seem to allready be aware when you scale to a certain extent you will run into all type of integrity issues but this depends on what you tolerance are for phantom reads, writes etc. Basically the more precise you want to be with your atomoticity the more of a bad idea it is.