My company is looking into writing a custom application that will need to perform many list item queries across multiple site collections. It will need to run for WSS 3.0 and it 'would be nice' if it worked on WSS 2.0 as well. It won't be designed for MOSS/SPS but again it 'would be nice' if it worked on these platforms. There is no restriction on which .NET version should be used for the solution.
For this type of application, what would be better: the object model/API or SharePoint web services? The primary factor I'm considering is performance, followed by features and functionality. Thanks!
Object model is better as you can gain access to additional features and the full detail of the list items, such as the version history.
The object model is also better for performance (as long as you dispose() your spsite and spweb objects properly).
The Sharepoint object model has some differences between 2 and 3, but if you look at the reference for v2 then it will also work fully with v3.
The web services have not changed at all between v2 and v3, which explains why they do not have any new features of v3.
The reason the object model will win on performance is that you will not be serialising the data as Xml and then transmitting a large chunk of Xml, and then deserialising the Xml. The object model spares your memory and bandwidth.
The first thing to consider is "will my code run on a sharepoint server or remotely ?"
If it's running remotely, you don't
have any choice, use web services
If it's running on a sharepoint
server, I would suggest using object
model, as performance will be
better, you'll have access to more
API and authentication will be
easier (=automatic).
+1 to the other posters.
If you decide to go the OM route then you can compile for both WSS 2.0 and WSS 3.0 from the one source. These should get you started.
Developing for Sharepoint 2003 using Visual Studio 2008?
How to reference two versions of an API?
Can the OM be used inside an Infopath form? Currently I'm using the web services to pull in the list data I want but I would rather use the OM.
Related
I'm currently looking at the feasibility of converting our current WCF Data Services OData provider to Web API OData.
I'm just a little confused at the OData implementation for Web API. With WCF Data Services it sits over the top of our ADO.Net entity model which exposes a bunch of tables from the SQL Server backend, i.e. you give WCFDS the ADO model to generate and then you have access to all of the tables through the standard OData syntax.
With Web API from all reading so far do we create a controller or separate actions for every table/object that we want to expose? Am I missing something? Is there just a way where the OData Web API controller can just expose the entire model from the ADO Data model? Having to create a action for every table would be a mess and overkill.
Currently if we need to add a table we just map it in the EDMX and WCFDS will automatically expose it as it's mapped to the entire context of the model.
Generating the model(s)
You can:
Use the convention model builder from ASP.NET Web API. This generates a different model than what EF's own convention model builder produces: an EdmLib IEdmModel. See this question though if you're using model-first or database-first. This method seems really backwards, and it is, but it mostly works.
Serialize the EF model and rebuild it as an IEdmModel (see this question). Again this is really inefficient. If you're using model-first or database-first, you'll want to just deserialize the EDMX file to build the IEdmModel. It still produces a different model internally, but at least the CDSL is a more stable format than CLR code conventions, so you'll probably have less surprises than you'd get when using two different convention-based model builders.
The reason for this is that ASP.NET Web API OData extensions use EdmLib, while EF uses its own code, and there is no plan to make them work together. Maybe you'll find this rant useful if you're curious.
Working on the API
Once you've generated the model from a unique source (so that you can work on your model from a single place), you'll indeed have to create a controller per entity, basically. The point of Web API is not to build things automagically, but to offer flexibility to the developer. The EntitySetController helps reducing redundancy, but it won't offer everything out of the box.
Taking a step back
In the rant mentioned above, I also talk about the difference between a service-layer API and a data-layer API. ASP.NET Web API is better suited for services, while OData makes services awkward. On the other hand, OData makes data access a breeze (essentially being like a RESTful SQL) and by virtue of being directly attached to the data model, can automate a lot of things as you saw with WCF Data Services. ASP.NET Web API with OData extensions sits in the middle, and its value is not universally agreed upon (using certain bits of OData URI syntax on service APIs is certainly useful though).
Don't get too hyped up by the recent buzz around ASP.NET Web API, it and WCF Data Services are very different beasts and run on different layers in your design. Indeed, in a multi-tier architecture, you could very well see a service API built using ASP.NET Web API sitting on top of an OData API built using WCF Data Services.
My advice is think carefully about what you're trying to build, and depending on the answer, either choose ASP.NET Web API and embrace the fact that the API you expose will be very different from a data-centric OData API, or stick with WCF Data Services.
A possible plan
You can find a lot of material on the web about service-layer APIs on the web by searching for terms like "non-CRUD web/RESTful/hypermedia API" or by comparing products like ServiceStack, which advocate for less data-oriented APIs.
If you're still unsure about the nature of your project, prototype it.
If you end up with a bunch of essentially identical controllers with Web API, each mapped to exactly one entity, then your API is heavily data-oriented. Go with WCF Data Services.
If you end up with a lot of OData Actions and awkward entities with WCF Data Services, then you need more domain logic on the server-side of the API, and data-orientation doesn't offer you enough. Go with Web API. A good rule of thumb here is to treat OData actions just like you treat stored procedures in a SQL DBMS. Actually, treat any OData server as a DBMS, because that's what they are. If you wouldn't put it behind a SQL interface, don't put it behind an OData interface.
Important (Update)
It was announced on March 27th 2014 that WCF Data Services would be discontinued by Microsoft in favor of ASP.NET Web API. To handle the "data-layer" use-cases I've exposed here, Microsoft has said that it is planning to extend ASP.NET Web API. Some community efforts are also underway. WCF Data Services will also be open-sourced at some point, so it's not impossible that a new maintainer will takeover, though it's uncertain.
Hi i am developing a metro style application where i will be connecting to web services and get the data from the web service and i will be binding it to the UI.
But my requirement is in my application i need to create tables and also provide relation between the tables and dump the data in to that local database and use that data in calling the other methods present in my service application (calling one more method in services by passing something as an input to that).
Can you please explain me the following :-
What is Database which is supported for metro style apps?
How can i create a database and create tables and dump the the data which i got as the response from my service application?
I am new to Metro style application development please help me out .
Thanks in Advance.
First of all WinRT has very poor db support. Most of this kind of things are done by web services, OData etc
BUT I`m almost 100% sure that you can use SQLite. On codeplex there are connectors from Win8 Metro app to SQLite DB so check this topic. I also saw somewhere on MS page that SQLite is support in some way. Check it
What Fixus said is correct. Personally , since my app doesnt have a large amount of data to store locally (it goes against the Metro guidelines to store large amounts of data) I serialize the objects instead to local storage. When needed, and if internet is available, the services will be called and the local data updated.
If you choose to use SQLlite make sure you use the real deal and not a third party db, as the DB library must be approved by Microsoft if you want to get the app accepted to the windows store. I'm not even sure that SQLite is yet approved, but by the looks of it they will be.
Tim Heuer always writes great articles on the subject, this one might help you
Let me know if you need help with serializing in WinRT, if you need it.
Best of luck!
We recommend using SQLite database with LinqConnect - Devart's LINQ to SQL compatible solution which supports SQLite engine (provided by http://code.google.com/p/csharp-sqlite/). You can employ LINQ and ADO.NET interfaces with our product. Starting from the 4.0 version, LinqConnect supports Windows Metro applications: http://blogs.devart.com/dotconnect/linqconnect-for-metro-quick-start-guide.html.
If you're building some application that has to keep working without any network connection, and needs to synchronize at some point in time, it is necessary to keep a local database.
You can read the following article, which has some basic guidelines and samples.
http://blogs.msdn.com/b/win8devsupport/archive/2013/01/10/using-database-in-windows-store-apps-i.aspx
I am developing a intranet sharepoint 2010 and to optimize the performance I would place much of data that is used for example to fill comboboxs and ListViews in the cache. What is the best approach to implement this feature? My idea was to use the ASP.NET cache.
Note: Much of the data are returned directly by web services and others are external sharepoint lists. The site will be installed in a web farm.
I suggest using the ASP.NET cache. Then you do not have to create your own and implement thingies such as thread support, dependencies etc.
Like most of the SP farms out there, if you have multiple web front ends (WFE's) in your farm then simple asp.net caching methodology is not going to be enough and might not work at all in some cases.
You need a product like NCache/Appfabric. It gets complex if your sharepoint environment has multiple farms distributed across the world.
Without reinventing the wheel, what I can use to manage user sessions in a web application and being able to respond with JSON to ajax requests?
Is there some framework (made for example with Indy components or something like this)?
Note for bounty:
in practice it is enough for me to have a reply with a clear example of a server application that serves json. Somehow a Delphi example of the php example mentioned HERE. (without the DB part, I want to see the basics of what does it mean to send JSON. I have basic knowledge of TIdHTTPServer.)
You can take a look at our Synopse SQLite3 Framework, which was just updated to version 1.11.
It serves the data in pure JSON, ready to be used in any AJAX application.
You can also easily create Services, more precisely Client-Server JSON RESTful Services. In this case, you can even not use SQLite3 for your data storage.
This framework is pure Open Source, compiles/run/is tested for Delphi 6 up to XE, is Unicode ready for all versions of Delphi (it uses UTF-8 internally).
By using this framework, you could be able to create easily also Delphi clients, using JSON data from the same server.
There is no internal User session handling yet. Because there are several way of implementing them, and, since our framework is RESTful, it's therefore stateless: no session is needed.
If you need it, I could easily add HTTP sessions using Cookies. What about the User authentication you are expecting?
Maybe this can help you:
REST Servers in Delphi XE Using DataSnap Whitepaper
Learn how to build REST servers using features available in Delphi XE, how to extend them with extra Delphi support code and how to take advantage of the jQuery library.
Marco Cantù
http://app.en25.com/e/er.aspx?s=608&lid=4414&elq=d428643420d2494581299418d9753feb
DelphiMVCFramework does this
Some notable features:
RESTful (RMM Level 3) compliant
Can be used in load balanced environment using Redis (http://Redis.io) [dev]
Fancy URL with parameter mappings
Specialied renders to generate text, html, JSON
Powerful mapper to map json to objects and datasets to objects
Can be packaged as stand alone server, apache module (XE6, XE7, XE8) and
ISAPI dll
Integrated RESTClient Works with XE3, XE4, XE5, XE6, XE7
and XE8 Completely unit tested
There is a sample for each functionlities
There is a complete set of trainings about it, but the
samples are included in the project Experimental support for IOCP
[dev]
Server side generated pages using eLua (Embedded Lua) [removed soon]
Specific trainings are available (ask me for a date and a place)
Messaging extension using STOMP (beta)
Community driven (Facebook group https://www.facebook.com/groups/delphimvcframework)
Simple and documented
There are books that talk about the framework
Project web site: https://github.com/danieleteti/delphimvcframework
N.B. I'm the main developer
I would suggest Delphi on Rails, it is an open source REST/MVC/StateLess web framework.
http://code.google.com/p/delphionrails/
It use:
superobject JSON parser
UIB/Firebird JSON driver
Cairo for SVG, PDF, PNG rendering
LUA for scripting/template ...
It is able to serialize automatically Delphi data structures to JSON using the new RTTI introduced in Delphi 2010 & XE.
I would recommend Super Object Toolkit.
http://www.progdigy.com
Example Code:
procedure Share(ARequestInfo: TIdHTTPRequestInfo)
var
ReturnObject: ISuperObject;
begin
ReturnObject := SO();
ReturnObject.B['success'] := false;
AResponseInfo.ContentType := 'application/json';
AResponseInfo.ContentText := ReturnObject.AsJSon();
end;
Daraja HTTP Framework, which uses Indy internally and adds a high level API for "web application contexts" and request mappings, loosely inspired by the Servlet API.
If you already have experience with TIdHTTPServer, you can directly access and adjust the server component according to your needs.
For JSON, you may use the built-in JSON support in newer Delphi versions or a third-party library (e.g. JsonDataObjects).
Disclaimer: I am the developer of the framework
All,
I'm beginning to explore what frameworks (open source) and tools for building web applications. What should I select and learn for the following layers,
Layer 1
Client side JavaScript / AJAX library or framework that will invoke REST style services provided by layer-
2
Layer 2
Provides a framework to rapidly create REST style services out of existing applications and out of a NoSQL document oriented database provided by layer-3. I need this layer in cases where I need to expose REST style services out of my traditional apps and RDBMS.
Layer 3
Which NoSQL to use - CouchDB or MongoDB that would work well with layer-2?
Will I need a MVC framework like RoR or a web/component framework like Wicket? Am I missing anything?
I also need recommendations for which tooling/IDE (and associated plugins) for the development environment. Thanks in advance for your answers/thoughts.
We've had pretty decent luck using a Java stack:
For the presentation, we use jQuery and jQueryUI, with Freemarker for XHTML/CSS templating, including to invoke REST web services through various UIs.
Restlet (www.restlet.org) is a wonderfully rich framework for crafting REST web services in Java. We decided to use it on a major product after it was strongly recommended to us by the engineering director of a top 10 e-commerce site in the US. And everything he said about it was true.
Unless you know you're going to face a really large amount of write volume, you're probably best off using one of the tried and true SQL databases supporting ACID transactional guarantees. We used Oracle, then switched to PostgreSQL, using the MyBatis (formerly iBatis) SQL Mapper to shield our code from the details of the database. With the advent of 64-bit addresses and scads of inexpensive DRAM, plus SSDs, these old workhorses do scale quite high.
If you are anticipating very large amounts of writes, by all means consider a so-called "NoSQL" database. I heard very good things about Vertica from the top network ops folks at a major technology company last week. MongoDB and CouchDB both look interesting. Or you may be able to leverage persistent distributed cache technology like Redis or EhCache to offload a traditional database.
The task you're trying to accomplish determines the technology you use.
If you're interested in the .NET platform, consider:
RavenDB for the data layer.
WCF Data Services for your REST services layer. Here's a guide to WCF Data Services with some great video tutorials.
If you need a web front-end, consider ASP.NET MVC or plain HTML as you see fit. jQuery and AJAX modules are well suited in both.
Arguably, ASP.NET MVC IS a REST endpoint of sorts, so you could skip the WCF services.
All the above can be leveraged with free tools, including:
Visual Studio Express
Raven DB's HTML interface at http://localhost:8080/