Sometimes when we learn of a new technology we tend to want to use that technology for everything. In many cases this is a good thing, in other cases you end up pounding a square peg into a round hole. Perhaps the round hole hole is large enough to accommodate the square peg, but it is still not the best fit.
You probably have several projects that SData can fit into. Perhaps integrating with a third party application or data loads from remote employees. Stuff like that. It makes sense to use SData when the systems are different enough -- Java interfacing with ASP.NET -- or far enough apart -- the application is not able to communicate with the database via other means. It is ok to be excited about the newest method to retrieve data from SalesLogix. Once you understand SData and have learned to use the client libraries then the world is yours.
In SalesLogix training we usually get questions when something goes wrong not when new code is being written and everything is going fine. Recently we had the chance to work on a new project that was going just fine, but we were asked to work as developers on the project. The project was a web based project written in ASP.NET (C#) and would in all likelihood sit on the same web server as the slxclient portal. A request would come into this website against one of about 7 pages. It would contain an xml feed. The page would take the xml feed and fill it in with data from SalesLogix and return the filled in xml as the response.
Using SData you would have had the initial request to my page, the http request from my page to SData, and then SData's request to the database using the entity model. Since the new website sat on the same web server as SData, you can be sure that there is a port open (probably 1706) to the SalesLogix server, and that we could use ADO.NET to eliminate that last request from my webpage to SData.
The final result
The final result was we ended up with a website returning xml data which it retrieved using ADO.NET directly from the database. Nothing fancy -- the same thing we have been doing for years. We were not using SData at all though. No client libraries were used just plain old ADO.NET and ASP.NET.
By not using SData we were also not using the entity model. This means any onbeforeupdate type events we had written will not be used. The argument can be made that these are important and if that is the case SData or working directly with the entity model is a good option. The learning curve of working directly with the entity model outside of SalesLogix might outweigh the gains initially, but the performance and code reuse benefits will certainly be there.