I wish there was a Sitefinity Runtime that allowed the for the Sitefinity API to be used in non-Sitefinity applications
We have a strict policy against using WCF due to the complexity of how to configure them. The problem we have experienced with WCF is that as the size of our database grew the WCF's started to fail left and right. Sometimes we could fix them by maximizing certain settings in the web.config but ultimately we ended up getting rid of all WCF.
What would be nice to have is an API that uses a connection string to communicate with the database. It would be really fantastic if perhaps a constructor could be used to specifiy the connectionstring name. This way we could create multiple instances of the API with each one communicating with a different Sitefinity application.
Below is how I would I like it to work. In this case "PublicWebsite" would be the name of a connection string stored in the web.config.
App = New App("PublicWebsite");var blog = App.WorkWith().Blog().CreateNew().SaveChanges();
Questions
1. Is this something that Sitefinity would ever consider?
2. I'm thinking of creating SQL views on the Sitefinity database so I can query it from other applications. This approach appears to be my only option (since WCF is forbidden in our company). How bad is this approach if I only use it for reading data?
You can write your own MVC or WebApi or ServiceStack services to access and update data in your Sitefinity system. These, like WCF, are just other front ends to the data behind.
I would suggest it is not a good idea to write views (or any direct access) to the Sitefinity tables as Sitefinity will update and later these as it requires for new releases.
Through unit testing the risk in writing SQL views can be minimized. Sitefinity periodically makes changes to its API that can also break an application. Those changes can be harder to fix as they require making changes every where they are used. Those fixes also require going into your projects source code make changes and re-compile and re-deploy. If Sitefinity changes the database schema I only have to make one change to the view.
Plus creating SQL Views in Sitefinity opens up a lot of doors in what you can do with the data. I can access the Sitefinity data as a SQL View in any of my other database applications and write joins and stored procedures against it. It also lets me use my favorite modeling tool with Sitefinity, since my modeling tool accepts SQL Views.
Using SQL Views reduces the complexity in building the application as it relies on fewer technologies and fewer points of failure. Without all the added complexity and layers, perfomance will likely improve, as well as the cost to build and maintain.