5 ms·

Depends what "disconnected" means. Before Object Relational Mappers came along, you wrote a load of SQL in Stored Procs or in some other framework. This was sup

Depends what "disconnected" means. Before Object Relational Mappers came along, you wrote a load of SQL in Stored Procs or in some other framework. This was super tight coupling because updating the database version could ruin everything. Not everything was in compiled code, so it was hard to track. If you use an ORM (such as Entity Framework I'm about to mention but there are lots) for the write/mutation part then the ORM provides you with that disconnect. You might want to use a different mapper for read, that allows you to write efficient SQL that meets particular needs. For example, a few years back in .NET Framework I swapped a system that designed/built on Sql Server to run on Postgres. Took me a few days. I didn't change any domain logic during that time. I'd say that the ORM provided a disconnect between the actual persistence and my domain. I do like a disconnect between my API and the database so that I am able to update the database without causing issues with consumers of my API. That usually requires some kind of mapping but only once. My preferred model right now is a CQRS (don't need ES) using Paramore's Brighter command pattern. That's for an RDBMS, I think with schemaless/DocDB you can go even further but then the code that loads out the data needs to deal with missing values. That's a different sort of constraint. I hope that helps, I think I'm rambling now.

kenniskrag 5y ago
I usually create "Service" classes in the domain layer, which use Repositories. These repositories are a wrapper for the DbContext to allow unit testing. Where do you put your domain logic? Do you have a domain model or is your persistence model your domain model?
- telchar 5y ago
  Can you expand on how those repositories are written and how you use them for unit testing?
- brainwipe 5y ago
  Domain model is the peristence model. Splitting them apart is often known as an anemic domain model (in Domain Driven Design). All the domain logic is on the entity. So our command handlers (akin to your service methods) look like: 1. Load entity 2. Call method on entity, passing in data 3. Save entity 4. Raise events So we only unit test 2. because that's the domain code. Loading entities from the dbContext is someone else's code. So is saving. So is raising events. If your entity class gets big, split out the functionality into other classes so that you end up with a fair portion of bodyless methods. Hope this is making sense!

kenniskrag 5y ago

I usually create "Service" classes in the domain layer, which use Repositories. These repositories are a wrapper for the DbContext to allow unit testing. Where do you put your domain logic? Do you have a domain model or is your persistence model your domain model?

telchar 5y ago
Can you expand on how those repositories are written and how you use them for unit testing?
brainwipe 5y ago
Domain model is the peristence model. Splitting them apart is often known as an anemic domain model (in Domain Driven Design). All the domain logic is on the entity. So our command handlers (akin to your service methods) look like: 1. Load entity 2. Call method on entity, passing in data 3. Save entity 4. Raise events So we only unit test 2. because that's the domain code. Loading entities from the dbContext is someone else's code. So is saving. So is raising events. If your entity class gets big, split out the functionality into other classes so that you end up with a fair portion of bodyless methods. Hope this is making sense!