I read about the new feature Auto Query. But if we don’t use ORMLite is not useful. Previous version had also new features of ORMLite. All these, are very good, I suppose. My question is , in general, that for users that they don’t use ORMLite or Redis, but only simple good services (RESTFul mainly) other features are important. As we have voted in user voice (e.g. signalR integration, Azure Directory etc) . I use ServiceStack for services only, maybe it would be better to have different versions. Also to have different roadmaps. I would like to know what to expect during next months for the services part, that I need.
Stephen Brannan:
I’d like to second this too. I don’t use ormlite either. In my case I use nhibernate. I to would be more interested in items other than servicestack’s orm features.
Hang on a second here, Improving OrmLite was one of the most requested features it’s also one of the least invasive ORMs since it just uses an ADO.NET connection and POCOs but it’s typed API still let’s us provide cross platform support for all major RDBMS. It takes 1 line to register and all SS features that use ORMLite pretty much hide from even knowing how to use ORMLite. Just because you don’t want to use it does not mean I’m not going to further improve it for everyone else that does. Part of SS’s value proposition is that it provides a full stack, which you’re free to use all of or part of. There will always continue to be improvements to all parts of SS. No features that use ORMLite are in SS.dll (which has no dependency on ORMLite), they’re all in SS.Server dlls. There’s no committed roadmap for SS, for the same reason why most other Tech Company’s don’t commit to roadmaps and only announce features when they ship.
Stefan Tsalapatis:
+Demis Bellot
As I wrote from the very first, I suppose all these new features are very good. I cannot argue with you. It is your company and you know the best .
Sir Thomas:
For what it’s worth, ServiceStack + OrmLite was an awesome find for my crew, it’s what drew us in. (Combined with the services framework no doubt) Let us clean up previous dapper related code, and overly cumbersome repository classes, etc.