Short intro: I build an application, using .NET, Entity Framework (EF) as ORM and an SQL Server for persistence. My knowledge of SQL Server goes far beyond simple requests, and I use it to drastically cut on DB operations. Still I prefer to use EF to cut on writing direct SQL when possible.
I have an application service, f.e. IDogsService, which I would like to implement in the core. Implementation will have EF context (a repository) injected and should use the injected context for persistence. This is what I believe my architecture should be, according to DDD.
But I do everything differently. While IDogsService interface is in the core - implementation is in another project. And that implementation does not have any repository injected- it simply uses an internal db context, defined in the same project. The reason for such decision is simple: while core knows nothing about the repository, the IDogService's implementation may behave the way it wants, when it comes to persistance. And I believe the core should not care about repositories at all.
Pros of such approach: my db context is able to use all the benefits of SQL Server, therefore increasing performance. Cons: service's business logic is moved out of the core (I think it should stay in the core).
I have a strong feeling all of this is wrong and should be architected a little bit different. But do not know how. I really do not want to turn towards a repository pattern, since it will take away the benefits of SQL Server in favor of other RDBMS'es.
Any experience to share?