Showing posts with label Client Object Model. Show all posts
Showing posts with label Client Object Model. Show all posts

Sunday 1 May 2011

SP2010 Data Access options for developers

Overview:  This post contains 4 wmv's that explain both client side and server side data access options for developers.  This was a single pesentation that I have broken up into 4 smaller units of 10-15 minutes each is about 15 Megs in size. 

Part 1 - Overview of Data Access options for SharePoint 2010 developers
Part 2 - Introduction to LINQ to SharePoint
Part 3 - More options
Part 4 - LINQ to SharePoint tips

Tuesday 28 September 2010

SP2010 Connections Conference in The Hague - Day 1

Keynote by Steve Fox was good but felt too sales orientated.  It's always hard to deliver a keynote at a  technical conference with the variety of attendees.  So overall not the worst and it covered a lot from previous conferences so not much new information outside of prepare for Azure with SharePoint.  Also SP1 for SharePoint 2010 will be available sometime in 2011 Q1.

Andrew Connell - AC is always good value however today he had a problem with his laptop/VM and the demos didn't work, still a good presentation on building RIA Rich Internet Applications or as the slide read "Rich Business Applications".  Looked at 2 demos for building RIAs using Silverlight client object model vs Restful web services (*.svc), nothing ground breaking but useful if you are new to using the Client Object model.
  • SharePoint apparently in it's page headers returns how busy the SharePoint server is with a number between 1-10, 10 being very busy.  You can see this in fiddler.
  • Anonymous user sites should generally use RESTful WS rather than Client OM/Silverlight as you need authentication. 
Ted Pattison's Extending the Visual Studio 2010 SharePoint tools was a great session.  Forget T4 templates.  Extensibility projects (VSIX) uses .NET4.0 and is based on MEF.  It's pretty straight forward and I can't wait to build some templates for SP2010.

Michael Noel's session on on Disaster Recovery & High Availability cover load balancing (use sticky sessions, Hardware is better than Sw load balancing), search options and improvements of MOSS search, SQL clustering and mirroring, use SQL alias's for pointing your farm at the db, common farm architectures, SP2010 and virtualisation (not ideal for SQL server), 3types of mirroring, Split content db's but not too small, Backup options and i need to review MS's DPM product.

Went to Andrew Connell's LINQ to SharePoint 201 Best practices.  Key takeaway is SPMetal only works on native SP Foundation types, M+LINQ to SharEPoint can be extended as it is implemented using partial classes, the iCustomise interface helps extend SPMEtal for more complex types such as Html fields and Metadata.

See Razvan-Petru Radu conference notes

Sunday 6 June 2010

Application Architecture in SharePoint 2010

Problem: I have a client that needs a composite built using 2010. The application is used to manage digital assets for suppliers. Key questions are where to store data and how to access the data.
Hypothesis: Where to store data, previously in MOSS I would of used SQL Server and accessed it via the BDC or custom web parts. In SP 2010 lists have been vastly improved and are now a good option for storing data. The new External Content Type can be used on SQL but goes beyond my requirement.
The key improvements to SharePoint lists are:

  1. Lookup lists are improved and easier to implement;
  2. Query joins and LINQ improve retrieving data;
  3. LINQ gives you strongly typed lists which using the old "Server Object Model" were weakly typed;
  4. LINQ querries are converted to CAML querries and therefore more performant than using the Server object model method and alot cleaner than using CAML to query data;
  5. Formula based validation on fields;
  6. Store level enforcement (MOSS enforce requirements such as null values only at the UI level);
  7. Improved referential integrity between lookup lists.
My choice was between using SQL Server to store the application data and SharePoint lists. SQL tables have the following key advanatages of they are more performant, and are transactionable. The easy of use and adavantages meant that SharePoint lists are the prefered option for storage.
Application for the suppliers and users also has several options however SharePoint provides most of the admin screens. The actual app can be built using application pages or web parts or the method i prefer, the client object model.

Accessing SharePoint Data options to consider are: Client Object Model (Weakly typed), however REST API's are Strongly typed for SP lists only. New in SP2010
Server Object Model (OM) is weakly type lists but offers the most flexibility. The Server OM existed on MOSS but is improved in SP2010. LINQ gives strongly type SP lists that can be read-write (new in SP2010)
Resolution:
Used SP lists to store the digital assets, the ordering data is also stored in SharePoint lists. For speed of development in the prototype I built using application pages using web parts that accessed the lists using LINQ to SharePoint. The final application will be built using the Client OM.