2

Based on this documentation here: http://docs.servicestack.net/physical-project-structure I wasn't able to quite figure out where \ how would be most appropriate to organize OrmLite within ServiceStack in order to have code-first structure and migrations etc.

Any suggestion what's would be best practice for this?

Gray
  • 115,027
  • 24
  • 293
  • 354
ShP
  • 1,143
  • 1
  • 12
  • 41

1 Answers1

1

OrmLite works with dependency-free POCO (Plain old C# Objects) which can be maintained anywhere as you see fit depending on the complexity of your solution.

This answer explores the simplest approach of where you can reuse your DTOs for your OrmLite models. When your needs diverge and you need to separate your DTOs and your Data Models, e.g. more fields were added to the RDBMS table than you want to return, you can maintain them in your ServiceInterface implementation project.

When the complexity of your solution grows and you have other components that needs access to the Data Models independently from your Service implementation than you can move your OrmLite models in its own DataModel project. Note: Your "model" projects should have the minimum dependencies required and all your logic projects should be depending on them and not the other way around.

Community
  • 1
  • 1
mythz
  • 141,670
  • 29
  • 246
  • 390
  • So for example I would have MyProject.ServiceInterface, MyProject.ServiceModel (which would represent my DTOs), MyProject.DataModel which will represent OrmLite models, and where needed in my ServiceInterface or some layer in between DataModel project and this one I can do transformation into DTOs (ServiceModel) objects, right? – ShP Mar 23 '17 at 19:30
  • I'd personally keep it in a DataModels folder `ServiceInterface` to start with and only move it into a separate project when needed. Note if you're going to have separate DataModels and DTOs you'll want to use the [built-in AutoMapping](http://docs.servicestack.net/auto-mapping) to easily map between them. – mythz Mar 23 '17 at 19:37
  • And you would suggest keeping these separate DTOs in the same project (ServiceInterface under DTO s folder or something))? – ShP Mar 23 '17 at 19:46
  • @ShP No, [please read this answer](http://stackoverflow.com/a/32940275/85785). Any Type that your Service Accepts or returns is a DTO which should always be kept in a separate `ServiceModel` project. – mythz Mar 23 '17 at 19:59
  • do you consider ViewModel as DTO as well? I mean if we have ServiceInterface project which should return ViewModel object, which is translated with Automapper from DTO from ServiceModel project which represent DB, where would you put ViewModel classes in order to use them in separate web project and in service interface project? – ShP Mar 30 '17 at 18:05
  • @ShP Any Type that your Service accepts or returns (i.e. forms part of your Service Contract) should be in the ServiceModel project, any other model used internally within your Service shouldn't be. – mythz Mar 30 '17 at 19:33