Some practices we employ based on our production experience:
•Validate connections when retrieving them from the connection pool.
•Write your service code to not assume that connections are valid - failure to do so can cause quite a bit of grief especially in production environments
•Wherever possible, explicitly close and dispose connections after using them (using(conn){} blocks work well)
•In a service, you should use connections for the shortest time possible - particularly if you are looking to create a scalable solution.
•Consider using explicit timouts on requests appropriate to the typical duration of a request. The last thing you want is to have one type of request that hangs to potentially block your whole system.
•Wherever possible use bind variables to avoid hard parses at the database (this can be a performance nightmare if you don't start out with this practice). Using bind variables also protect you from basic SQL-injection attacks.
•Make sure you have adequate diagnostic support built into your system - consider creating a wrapper around the Oracle ADO calls so that you can instrument, log, and locate all of them.
•Consider using stored procedures or views when possible to push query semantics and knowledge of the data model into the database. This allows easier profileing and query tuning.
•Alternatively, consider use a good ORM library (EF, Hibernate, etc) to encapsulate data access - particularly if you perform both read and write operations.
•Extending on the above - don't pepper your code with dozens of individually written SQL fragments. This quickly becomes a maintainability nightmare.
•If you are committed to Oracle as a database, don't be afraid to use Oracle-specific features. The ODP library provides access to most features - such as returning table cursors, batch operations, etc.
•Oracle treats empty strings ("") and NULLs as equivalent - .NET does not. Normalize your string treatment as appropriate for Oracle.
•Consider using NVARCHAR2 instead of VARCHAR2 if you will store Unicode .NET string directly in your database. Otherwise, convert all unicode strings to conform to the core ASCII subset. Failure to do so can cause all sorts of confusing and evil data corruption problems.
I hope this post will help many of you feel comfortable with using the Content Query Web Part. In this post I will walk you through the process of creating a content query web part and configuring it to show custom field types. I will also give details on how to use XSLT to stylize and format the data being pulled. I will be using the following scenario as an example. Say that you had a site collection with a top level publishing site. This publishing site would display a the most recent blog posts from all blog sites within its own site collection. To solve this problem we will use a Content Query Web Part and a customized ItemStyle.xsl using XSLT. Please note that the “SharePoint Server Publishing Infrastructure” needs to be enabled at the site collection to display the content query web part. Step 1: Add a Content Query Web Part to Page Navigate to the site that you want the blog posts to show up and click on edit page. Under Editing Tools in the Ribb
Yorumlar