Within the patterns & practices SharePoint Guidance, there are a few reusable components, such as Hierarchical Configuration, Logging and Service Locator. They are basic infrastructure for SharePoint applications. Here are some my thoughts.
1) The hint is that to start build any types of application, web application, Silverlight application and etc, the first thing is to get configuration, logging, service locator/dependency injection ready.
2) In .NET base class libray, there should be generaric interfaces, such as ILogger, IConfig for custom implementation, like the GeoAPI.NET, which provides OGC/ISO standards based interfaces to .NET GIS projects. Today, the ILogger defined in Microsoft.Practices.SPG.Common is useless to other LOB DLLs.
3) Compare to the Enterprise Library monster, Microsoft.Practices.SPG.Common is much lighter. But the ILogger and IConfigurationManager are coupled w/ SharePoint, and there is no dependency injection.
I am looking into the possibilities to implement dependency injection to SharePoint development, as I did for ASP.NET MVVM.
December 1st, 2009
My stories with WCF:
1) WCF is very easy to expose functions through different endpoints by just configuring endpoints. I created a WCF in Web application to serve Silverlight 2. It has a basicHttpBinding endpoint and a mexHttpBinding. It worked perfectly w/o change to serve Sliverlight 3. Later on, I added webHttpBinding endpoint (enabled web script). It worked with ASP.NET AJAX Client data template (not cross domain yet). Next I will try if it is possible to add a custom binding with binary encoding for Silverlight 3.
2) WCF is still too hard for non .NET clients. My client was a Delphi 7 program. It dose not support wsHttpBinding (SOAP 1.2). Even with basicHttpBinding (SOAP 1.1), Delphi could not generate proxy from the WSDL, because the WSDL of WCF uses "include". End of the day I created a ASMX wrapper around the WCF interface and implemetation. It was a success, because the ASMX follows the important concept of service interface, service implementation, service host and etc, just like WCF. In the future, if ASMX is need, I will start with WCF and wrap it with ASMX.
3) Nightmare of configuing the SSL for WCF. It requires to configure the base address in web.config. It was every difficult for a server that has many virtual sites. Metabase Exploerer is need to configure the IIS 6′ SSL binding.
4) Both WCF(basicHttpBinding endpoint) and ASMX work perfectly with my basice authentication HttpModule. As well as the ASP.NET client application (authentication) service.
For future reference, I need to write down my wresting experiences with a few commoly used WCF binginds.
- basicHttpBinding - SOAP 1.1
- wsHttpBinding - SOAP 1.2 (looks like it is only good for .NET client)
- webHttpBinding - HTTP/REST
- for ASP.NET AJAX Client/JSON, in web.config created a new endpoint with address "/ajax", and defined the <endpointBehaviors> to have <enableWebScript />, now the URL …/xxx.svc/ajax/js and …/xxx.svc/ajax/jsdebug return proxy in Javacript. The proxy is used by the client template for data binding
- for REST, in web.config created a new endpoint with address "/xml" and defined the <endpointBehaviors> use <webHttp/>. now the [WebGet] attribute works for URL …/xxx.svc/xml/Id=123. [XmlSerializerFormat] was used to control the XML schema structure.
December 1st, 2009