Starting development in EpiServer Find and EpiSErver CMS7.

This blog can help developers if they are just starting development In EpiServer Find and CMS I summarized these from find documentation and different forum posts.

To use the EPiServer integration we need the regular EPiServer Find .NET API as well as two additional assemblies:
Episerver.Find.Framework.dll
EPiServer.Find.Cms.dll (there are a number of built-in filtering extensions in the EPiServer.Find.Cms namespace)

Indexing
Indexing is the process of taking an object and sending it to the service for storage and analysis so that it can later be retrieved or included in search results. Joel explained these in a post in following words

PageIndexer.Instance.Index() will index a page in the same way as if the indexing was triggered by an event, such as the page being published.
SearchClient.Instance.Index() will index a page and only that page. While it will serialize it using conventions set up by the CMS integrations initialization module it will in all other respects index it as any other CLR object and not apply any other logic such.
Client.CreateFromConfig().Index() will index a page exactly as it would be serialized by JSON.NET out of the box, meaning that it will most likely fail, and even if it doesn't it won't index some additional fields (such as SiteID) that other parts of the CMS integration relies on.

Accessing the actual search results

When searching with the general .NET API search queries are usually executed using a method named GetResult which returns, among other things, matching objects or projections from matching objects by de-serializing them from JSON. However, when executing a query for EPiServer pages and files stored in VPP folder we often want the returned objects to be the EPiServer objects, such as PageData objects, returned from the EPiServer APIs and not objects deserialized from the index.
GetContentResult and GetFilesResult both return instances of a type which contain the matching objects, such as matching content objects. These types are ContentResult and FilesResult. This is accomplished by fetching the matching objects IDs from the search engine and then fetching the actual objects from the CMS' API.
GetPagesResult return instances of a type which contain the matching objects, such as matching PageData objects. Types is PagesResult.
GetResult: For scenarios where we don't want the whole IContent or UnifiedFile objects but rather a subset of their content, perhaps with highlighting we can instead use the regular GetResult method.

Sometimes we may need to use the actual search results (of type SearchResults), for instance in order to track statistics. Both ContentResult and ContentResult expose these through a property named SearchResult.

Caching
As opposed to the GetResult method which does not do any caching by default, the GetContentResult method automatically adds caching for an hour. However, to make sure that query results are not updated it adds query results to the cache with a dependency on the EPiServer master cache key. This means that the cache will be cleared whenever an EPiServer content is saved or deleted. This is similar to how the EPiServer output cache works.
Search request can be cached using a certain duration using the StaticallyCacheFor method which accepts a timespan.

Language handling
The GetContentResult method automatically adds a filter to the search request to select content from the current language branch as determined by the EPiServer LanguageSelector.Autodetect() method. To select pages from a specific language branch, an overload accepting a LanguageSelector instance can be used
SearchClient.Instance.Search<IContent>()
.For("banana")
.GetContentResult(new LanguageSelector("sv"));

Use SearchClient.Instance
When working with the general .NET API we typically create an instance of the IClient class using the Client.CreateFromConfig method. Following the general pattern of EPiServer development, the EPiServer integration provides a singleton instance instead in the form of the SearchClient class and its Instance property. The returned instance is a regular IClient, but some modifications are made to it at start up. In other words, when working with EPiServer and EPiServer Find, make sure to use SearchClient.Instance.
A typical implementation is
var client = ServiceLocator.Current.GetInstance<IClient>();
var p = client.Get<Profile>(userId);
Within CMS
var p = SearchClient.Instance.Get<Profile>(userId);
Why:
If one obtains an instance of the Client through for instance the static CreateFromConfig method it will be a vanilla client that doesn't know anything about specific types such as PageData. It will simply do it's best to index and search for any type of CLR object. However, since complex non-POCO objects such as PageData often contain circular references (A.PropertyB.PropertyA == A) and other obstacles for serialization some special handling, typically through modifications of the client's conventions is needed. For CMS objects, this will be taken care of by the CMS integration given that we're using SearchClient.Instance.

Accessing Instance of Find in above discussed manner will help in resolving issues like
Self referencing loop detected with type 'EPiServer.Core.PropertyLongString'. Path 'Blog.Property[0].Parent'.
Or Proprty Not Found.

http://world.episerver.com/Modules/Forum/Pages/Thread.aspx?id=60636&