3. About Me
• Benjamin J. Steinhauser
•
•
•
•
•
•
SharePoint Solutions Developer
B&R Business Solutions
BS/MS in CS; MCP, MCTS (SP2010 Config. & Dev.)
10+ years as ASP.NET Application Developer
5+ years as SharePoint Developer
Creator of Open Source CodePlex Projects
•
•
•
•
•
SPCAMLQueryHelper (over 25,000 downloads)
SPFileZilla (over 200 downloads)
SPMetroGrid
SPMMDNavigator
SPClippy, SPjQuerify, SPEasyBranding
• Presenter at SP User Groups and SharePoint Saturday Events
3
4. Intro
• Where do I put my application’s data?
• “Every custom SharePoint application is driven by data in one way
or another” –W. Wilen
• Developers face many choices when building solutions that
consume data
• “Knowing is half the battle!”
• Who: is the consumer of the data?
• What: is the type of data being saved?
• When: is the data needed, and for how
long should it persist?
• Why: is the data being stored in the first place!?
• Where: is the data being stored?
4
5. Cont’d
• What are the advantages/disadvantages for each option?
• What are the restrictions?
• What type of data is it?
• Settings, configuration, licensing
• Structured data (employees, favorites, HR forms, etc.)
• How long should the data persist?
• Who is the data consumer?
• End user, Power User, Administrator
• Web Part, Application Page, Timer Job, Web Service, Service
Application
5
6. Where is my data!?
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
MS SQL Server
SharePoint List
Property Bags
Web Part Properties
View State/Hidden Fields
Cache
Web.config
SPPersistedObject
Session State
Cookies
6
7. Databases
•
•
•
•
•
MS SQL Server, Oracle, MySQL
CRUD: create, read, update, delete
For structured data, relational data
Easy (if you know SQL), very fast
Ways to interact:
•
•
•
•
LINQ to SQL
LINQ to Entity
Stored Procedures
Inline-sql in .NET
• But…
•
•
•
•
•
•
Farm solutions only (not for Sandbox Solutions)
Database needs to be created (database administrator)
Permissions need to be configured (database administrator)
Contexts need to be built (when using LINQ)
Another actual “layer” to manage
Connections strings need to be saved (more data!)
• “Put it in a list, duh!”, not so fast, does it need the SP overhead?
• Better for custom business applications that store lots of data, specialized data,
data that doesn’t need to be accessible via a List, Searched.
7
8. SharePoint List
•
•
•
•
•
•
•
ECM: Site Columns, Content Types, Custom Lists
BCS External Lists too!
Provisioning, create on Feature Activation, WSP
Site level (root web), Web level
Accessible to Power Users and Admins
Sandbox Solutions supported
May ways to interact:
•
•
•
•
•
•
Direct access via SOM
LINQ to SharePoint
SPQuery (with CAML)
SPSiteDataQuery: cross site list queries
SP Client Object Model: from JS, Silverlight, .NET
REST
8
9. Cont’d
• Implementations:
• My Custom Config List
• Codeplex: http://spconfigstore.codeplex.com
• SharePoint Enterprise Patterns and Practices
• But…
• SharePoint overhead
• Permissions are very important
• RunWithElevatedPrivileges may be needed, or use current user
permission
• Across site collections gets tricky
9
10. DEMO: Config List Reader
• Custom List created in Feature Activation
• Filled with default data
• Custom Class: ConfigListHelper
• CreateConfigList()
• GetAllValsElev()
• GetAllVals()
• Custom application page:
• Reads all config data into Hashtable
• Displays to page
10
11. Aside: LINQ to SP
• Enables you to use Language Integrated Query (LINQ) queries
• Translates LINQ queries into Collaborative Application Markup Language (CAML)
queries.
• Sandbox Solutions supported
• From MSDN, steps to use LINQ2SP:
• Generate the entity classes. create or generate the strongly-typed entity classes
that represent your list data and lookup column relationships.
• Use SPMETAL.exe, batch file (.bat, .cmd)
• Develop the solution. write LINQ queries against the strongly-typed entities that
represent your data model.
• Run the solution. provider dynamically converts your LINQ expressions into CAML
queries, executes the CAML, and then maps the returned items to your stronglytyped data entities.
• Pros:
• No more CAML! Natural Language syntax or Expression syntax, FTW!
• Cons:
• Need to build context
• SPMETAL.exe by default builds entity classes for ALL lists, content types, etc.
• Can customize this with xml parameters file, see MSDN
11
12. DEMO: LINQ to SP
• Feature Activation, Event Receiver:
• Create List, “Best SharePoint Blog Sites”
• Fill with sample data
• SPMETAL BAT file, creates Entity context
• SPSVB2014Linq.cs
• Custom Application Page:
• Display ListItems
• Add a ListItem
12
13. Web.config
• Usually the first place “web developers” look to start saving settings
• We quickly find out that it’s a double edged sword
• Pros:
• Find file, open, add key/value pair, save … profit!
• 1 LOC to access data from app
• Cons:
• Farm solutions only (not for Sandbox Solutions)
• Have to update every WFE separately
• SPWebConfigModification can be used, which may “nuke” your
custom settings added manually (so I’ve heard)
• Need server access, admins only
• Either don’t use this, or use this for farm-wide settings that “need”
to be secured in web.config
• Better yet, use a nested web.config in your applications layouts
folder
13
14. DEMO: Web.config
• Nested Web.config file in app “_layouts/<appname>”
• Custom Class: WebConfigHelper
• Designed to use modes, makes it easy to store different
environments together (ex. dev, test, staging, prod)
• GetMode(): get the current mode
• GetKey(): get the key associated with the current mode
• Custom application page:
• Retrieves single property and displays
14
15. Property Bags
• Hashtable/Dictionary collections to store simple objects (string, int)
• Can use Serialization to save custom objects, Lists, collections, etc.
• PropertyBags are available here:
• Farm: Farm admins only; no Sandbox; WFE read-only(?)
• TimerJob: Each timer job has its own bag; Farm admins only; no Sandbox
• Web Application: Each web app has its own bag; Farm admins only; no Sandbox; WFE read-only(?)
• Site Collection (via root web): Web admin to edit; root web read access to read; Sandbox
supported
• Web: Web admin to edit; web read access to read; Sandbox supported
• List (via root folder): List owner to edit; list read access to read; Sandbox supported
• Pros:
• Easy to use, quick/efficient to store settings, small amounts of data
• Saved in content database
• Cons:
• Not meant for large data, approx. 4-8kb and below
• No interface to CRUD, build your own, or use a plugin (codeplex), or SPDesigner
• http://pbs2010.codeplex.com/
• http://pbs2013.codeplex.com/
15
16. DEMO: Property Bags
• Custom Class: PropBagHelper.SiteRootWeb
• SafePropBagSave(site, key, value)
• SafePropBagRead(site, key)
• SafePropBagRead(site)
• Custom Application Page:
• Get all root web keys
• Save a key
16
17. Aside: Serialization
• Serialization: converting an object into a stream of bytes, to store or
send the object
• Its main purpose is to save the state of an object in order to be able
to recreate it when needed.
• The reverse process is called Deserialization.
• We convert bytes to strings, to save in Property Bags, ViewState,
cache, etc.
• Popular Formats:
• XML Serialization
• SOAP Serialization:
Conform to the SOAP specification. SOAP is a protocol based on XML, designed specifically to
transport procedure calls using XML
• JSON Serialization
• Tools/API:
• NewtonSoft’s Json.NET
• My API
17
18. DEMO: Serialization
• Custom Classes:
• JsonExtensionMethod
• XmlSerialization
• Custom application page:
• Local class: Person
• On page load, Person created, Serialized to text,
displayed in textboxes
• Button to Deserialize, fill Person Objects, display IDs
18
19. Web Part Properties
• The Web Part base class contains a set of properties that users can use to control its appearance
and behavior (width, height)
• A custom property is a property that you create when you need additional properties to enhance
your Web Part's functionality
• The custom properties you create and specify as able to be browsed are displayed automatically
in the default property pane
• If the default property pane isn't rich enough in functionality, you can create a custom user
interface called a tool part to manipulate your custom properties
• Available in Sandbox Solutions
• Available in Standard and Visual Web Parts
• Standard Property Attributes:
• WebBrowsable = true, property visible to user in properties pane
• Category = “Licensing”, section where property added in pane
• Personalizable = PersonalizationScope.Shared, for all users
• Easy to update in custom tool pane Class, tricky to update in regular Web Part page lifecycle
events
• SetPersonalizationDirty()
• ***Checkout required, Content Approval, Publishing
19
20. DEMO: Web Part Properties
•
•
•
•
•
Web Part Feature
Add to page
Read web part property value
Update web part property value
Show in default properties pane
20
21. Temporary Data
• Per WFE all Sessions, or Per Session, or Per Web Page,
• Options:
• Session State: disabled by default in SharePoint, can be turned on
• ViewState: easy way to save data between postbacks, string data
only, but with serialization…
• Hidden Fields: with viewstate enabled (by default), can be useful
for mixing ASP.NET postbacks and JavaScript operations; only
saves strings, but with serialization…
• Cache: HTTPRuntime, Application state; server side cache, useful
for data that only needs periodic refreshing; per WFE, load
balancing may interfere; behaves like static/shared/singleton
• Cookies: ASP.NET management of client side cookies, or use
jQuery Cookie plugin (recommended)
• HTML5 web storage: not all browsers support it, but cool!
21
22. DEMO: Temporary Data
• Custom application page:
• Read/write ViewState
• obfuscated/encoded/encrypted in browser
• Read/write HiddenField
• accessible via JavaScript
22
23. SPPersistedObject
•
•
•
•
•
•
•
•
For storing settings at the Farm and Web Application level
For storing multiple settings and more complex values
Create a class that inherits SPPersistedObject
Add your settings as properties
Mark them as Pesisted (with attribute)
Then use SPFarm.GetChild or SPWebApplication.GetChild
Settings saved in SP Configuration database
Cons:
•
•
•
•
Requires Farm Admin to save settings
Farm solutions only (not for Sandbox Solutions)
There is no built in user interface to manage SPPersistedObjects
Must impersonate Farm admin to read and write, since access to
Config database required (RunWithElevatedPrivs doesn’t help)
23