Pro Entity Framework 4 0 Depositfiles_8

Tham khảo tài liệu pro entity framework 4 0 depositfiles_8, công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Pro Entity Framework 4 0 Depositfiles_8 CHAPTER 12 ■ PERFORMANCE TUNING AND EXCEPTION HANDLING Looking at the metadata section of the connection string of the app.config, you will notice that themetadata section has changed as well.metadata=.EF40Model.csdl|.EF40Model.ssdl|.EF40Model.msl; However, you don’t have to look at the app.config file to see the metadata changes. Whenever youchange the Metadata Artifact Processing property value and then save the EDM, you can visually see theConnection String property (Figure 12-10) change accordingly. You can also copy the schema fileswherever you want and specify the location in the metadata by specifying the location of the files.metadata=C:AWEF40Model.csdl | C:AWEF40Model.ssdl | C:AWEF40Model.msl So, the question is, why would you want to have the schema files outside of the binary assembly?The answer really boils down to how often you change the model after deployment. By separating theschema files from the binary assembly you provide a loosely coupled scenario. For example, non-breaking schema changes could be made on the database, such as adding a table, which allow you tomodify the SSDL and MSL to reflect these changes while the CSDL could be left alone. Be careful withthis. If you move these, and the ObjectContext cannot find them, an exception will be thrown.Exception HandlingLet’s talk about handling Entity Framework specific exceptions. Obviously we are not going to discuss allof them because that would take a really long time and be completely boring. However, we will talkabout how to handle specific types of errors and the best way to approach your code to handle theseexceptions. Some of what I cover is standard .NET error handling standards, while the rest is particular to theEntity Framework. We’ll begin by discussing some standard ways to trap and handle errors and thentake a look at some specific EF exceptions and how the standard exception handling can help. If you have been developing applications for any length of time you know that exceptions can begenerated from the second you launch the application all the way until you close the application. TheEntity Framework is no different. An exception can be generated from the moment you create yourcontext (by instantiating an ObjectContext) all the way through to the point you call SaveChanges. We canefficiently and elegantly handle these exceptions by using try/catch blocks supplied by the .NETFramework.Try/Catch BlocksTry/Catch blocks can be the cure to many headaches when used effectively. I’m hoping all of you knowhow to use a try/catch block, but in case you are new to .NET, the basic try/catch block looks like this:try{ // Do Something}catch (Exception ex){ // handle the exception} In this example, the try block is where you perform any task such as instantiating an ObjectContextor performing some queries. When an exception is generated within the try block, the flow is routed to 219CHAPTER 12 ■ PERFORMANCE TUNING AND EXCEPTION HANDLING the catch block where you can obtain error information and handle it accordingly. When exceptions are generated, the program automatically looks for the catch statement block to handle the exception. For example, the following code snippet uses the try block to instantiate an instance of the EF40Entities ObjectContext then creates a simple LINQ-to-Entities query. If an exception is generated, the flow is routed to the catch block and executes the throw statement. For those not familiar with the throw statement, it is a simple statement that is used to indicate an anomalous exception. try { EF40Entities context = new EF40Entities (); var query = from con in context.Contacts select con; } catch (Exception ex) { throw; } More on the throw statement and how it can be used can be found here: http://msdn.microsoft.com/en-us/library/aa664760(VS.71).aspx Optionally, instead of using the throw statement, you could display the message using the MessageBox class (if you are within your user interface) to display the exception, such as MessageBox.Show(ex.Message); The following code includes a finally block, which can be included as part of the try/catch. The finally block is useful for cleaning up resources allocated in the try block as well as running and executing any code that needs to be run, despite whether there is an exception. In other words, execution control is always passed to the finally block regardless of what happens in the try block, even if no exception occurred and t ...