Few questions about "Service" (with ormlite)

[mythz]

@avif

As far as I understand it a Service is more like a controller.

A ServiceStack Service is the implementation of a Web Service or HTTP API (it does support other use-cases but I’ digress). MVC Controllers is the C in the MVC pattern typically used to display server generated HTML UIs.

@avif

Is it suppose to be Per database entity?

Services have no correlation with a DB Entity, the Service should just be designed to accomplish what it needs to do. I wouldn’t try imposing a forced API design around rules like DB entities, you should have the freedom to accomplish each API as you see fit.

I’d recommend doing some reading through Background Concepts and the Getting Started Docs.

@avif

1. Where can I find documentation about IRepository , how to implement and best practices?

I don’t know what you mean without an example, but see the Routing for how to configure routing for ServiceStack.

@avif

Where can I find documentation about IRepository , how to implement and best practices?

Again I wouldn’t try forcing a design pattern, I’d adopt a simplicity-first gradual approach as I’ve described in this thread:

@mythz

I personally take a gradual approach where initially all my data access is kept in the Service, when I need to reuse data access implementations I’ll refactor it out into static extension methods, when it grows large enough that it needs more modular organization I’d use a “Repository” which inherits a custom RepositoryBase to reduce the boilerplate (but needs to be registered as a transient dependency so the open connection is disposed at the end of the request). So it’s essentially like option 1 but using a base class to reduce boilerplate. I’m not seeing the benefit from decoupling from IDbConnectionFactory as it’s defined in ServiceStack.Common which ServiceStack.OrmLite references so it’s not adding any additional dependencies/coupling.