SharePoint Timer Job vs Windows Task Scheduler

Scenario:
This is another common question which confuses lot of developers as which option is better. Traditionally they have been writing console application and running them using Windows Task Scheduler, then why do we need SharePoint Timer Jobs.

Pros and Cons:
Considering a FARM scenario...

Single point of failure : Windows Task Scheduler need to be configured on all the web servers. If you configure to run the job on 1 server only, and this server crashes, job will not work at all.

Interface : Windows Task Scheduler have much easier interface for scheduling option. SharePoint doesn't have a UI to configure the jobs. There is a codeplex project though to bridge the gap. Still its hard to configure a job to run every X number of hours in share point, where-as it's easier with Windows Task Scheduler using multiple schedule options.

Status Reporting : Windows Task Scheduler doesn't have any reporting on when was the last time job got executed and what was the status. Only option is logging. Whereas SharePoint have a UI to show status of all the jobs and their status.

Security : In case of Windows Task Scheduler, you will need go to IT Admins and request for a special username/password to run such jobs where as SharePoint Timer Jobs automatically run under SharePoint Timer Job account.

Deployment : There is no easy way to deploy Windows Task Scheduler tasks and application which need to executed in a FARM environment. This will require lot of manual steps by IT Admin. SharePoint jobs can be deployed using WSP's.

Winner
SharePoint Timer Job

SharePoint 2010 : Search Comparision

SPWeb.AvailableContentTypes vs SPWeb.ContentTypes

SPWeb.ContentTypes
- Gets the collection of content types for the Web site.

-The ContentTypes property returns only the content types that exist on the current Web site, not all content types in the current scope. Use the AvailableContentTypes property to return all content types in the current scope, including those of any parent Web sites. When you add a content type to this collection, you make it available to lists in the current Web site and in any child Web sites.

SPWeb.AvailableContentTypes
-Gets the collection of all content types that apply to the current scope, including those of the current Web site, as well as any parent Web sites.

-You can apply any content type that is returned in this collection to lists in the current Web site. However, you cannot add content types to the collection that is returned in this property. It is a read-only property. If you want to make a new content type available, you must add it to the collection that is returned by the ContentTypes property. That collection includes only the content types that exist in the current Web site.

SharePoint Lists vs. SQL table

First there are some obvious similarities.

Both structures : Let you define a structured repository for your data.Can be queried to retrieve all or part of the data based on specified criteria. But the differences are overwhelming: SharePoint Server automatically generates a powerful UI for SharePoint lists, both on the list administrator side and on the end user side. A dedicated UI would have to be created from scratch for SQL tables.

Compelling example is the ability for end users to upload files to SharePoint document libraries. The web pages to provide the upload functionality are generated transparently. Given the right permissions, business users can create and manage SharePoint lists relevant to their day-to-day work. Do not expect the same business users to create and manage SQL tables – they would not even have the tools to do it.

This has a significant impact on IT workload as more tasks can be delegated to end users.Complex workflows can be attached to data in SharePoint lists, to be triggered manually or whenever data is added or changed. Recreating the same functionality for SQL data would be a complex task involving IT.

By using SharePoint list views, business users can customize the presentation of data to fit their precise needs. In particular, they can filter, sort or group data in ways that make sense to them, without requiring IT intervention.

Content types can be specified to restrict what type of content can be included in a specific SharePoint list. This provides tremendous flexibility, while enforcing a comprehensive taxonomy.SharePoint lists can hold records as well as documents, images, InfoPath forms as well as other files. This provides a very generic way to store content assets.

Document management features like versioning, check-in/check-out, folders or content expiration can be enabled on any SharePoint list in a single click. Performance : SharePoint lists being generic has some performance limitation. Lists with more than 2000 items do not perform very good where-as SQL tables fly with large data. Note: Both SharePoint list and SQL table data can be made available in the search results of SharePoint Server. For list items, this inclusion is automatic. Records from SQL tables would be integrated by using the Business Data Catalog feature of MOSS 2007.

Site Template vs Site Definition

Site Definition Advantage:

• Data is stored directly on the Web servers, so performance is typically better.
• A higher level of list customization is possible through direct editing of a various XML files.
• Certain kinds of customization to sites or lists can only be done with site definitions, such as introducing new file types, defining view styles, or modifying the drop-down Edit menu.

Site definition Disadvantages:

• Customization of site definition requires more effort than creating custom templates. ( Not a big difference in effort if planning is proper )
• Users cannot apply a SharePoint theme through a site definition.
• Users cannot create two lists of the same type with different default content.
• Customizing site definitions requires access to the file system of the front-end Web server.

Site Templates Advantages:

• Site templates are easy to create.
• Almost anything that can be done in the user interface can be preserved in the template.
• Site templates can be modified without affecting existing sites that have been created from the templates.
• Site templates are easy to deploy (Basically just a file upload).

Site Template Disadvantages:

• Site templates are not created in a development environment.
• They are less efficient in large-scale environments, not very easy to move them across various environments.
• If the site definition on which the custom template is based does not exist on the front-end server or servers, the custom template will not work. The reason is that Site Template is a delta file applied on an existing Site Definition.

Application Pages vs Site(Content) Pages

SharePoint pages are built on the foundation of ASP.NET. As a SharePoint developer, you must be aware of two different types of SharePoint pages.Application pages and Site pages.Application pages, such as Settings.aspx, are used for all Windows SharePoint Services sites.

Therefore, if you modify or extend the functionality in this type of page, your changes will apply to all SharePoint sites. Application pages are stored in the file system of the front-end Web server.

They are located in the TEMPLATE\LAYOUTS folder in the Web Server Extensions path.Each SharePoint Web includes a virtual directory, named _layouts, that points to this physical location.So, for example, the Settings page is accessible by using the relative URL of /_layouts/Settings.aspx.

In contrast, Site pages, such as Default.aspx, can be customized on a site-by-site basis.Newly-created sites start with site pages based on page templates on the front-end Web server.

For example, sites based on the Team Site template contain a Default.aspx page from the TEMPLATE\SiteTemplate\STS folder. These pages are known as uncustomized pages.When a site designer or developer customizes a site page for a specific site, the customized copy is stored in the site database and served from there when requested.

ASP.Net Webpart vs SharePoint webpart

Web Parts and Web Part pages were introduced in a previous version of Windows SharePoint Services. In the previous versions, Web Parts were implemented as specific SharePoint-based classes. However, ASP.NET 2.0 includes a Web Part framework that provides Web Part page controls and a more generic, flexible implementation of Web Part classes. Windows SharePoint Services 3.0 uses the new Web Part framework. For example, you can develop a class that inherits from System.Web.UI.WebControls.WebPart and you can then use that class as a Web Part in SharePoint-based sites. Windows SharePoint Services pages include the ASP.NET 2.0 Web Part management controls so that users can add, remove, or modify the properties of ASP.NET Web Parts in a manner that is consistent with non-SharePoint Web Part pages.

When you develop new Web Parts, you should use the ASP.NET 2.0 classes as the start point for your development. However, Windows SharePoint Services 3.0 provides a very high degree of backward-compatibility with previous versions. If you have already developed Web Parts based on the previous version of Windows SharePoint Services, those Web Parts can still be used in Windows SharePoint Services 3.0 sites. For example, if you have developed a Web Part based on the Microsoft.SharePoint.WebPartPages.WebPart , you can still use it in Windows SharePoint Services 3.0 sites.