0

I am using Entity Framework and an onion architecture to make my website maintainable and persistent. Now as I followed a particular onion architecture example, I ended up with:

  1. Domain (entities, and domain interfaces)
  2. Repository (IRepo, and Repo etc...)
  3. Service (established a link between UI and Repo, to respect SoC (if I got it correctly) etc ...)
  4. UI (in my case an MVC project)

Now I have separated my Entity Framework entities from my context. Entities go in the domain whereas the context goes in the repository. This means that when I enabled migrations, the configuration.cs file has been added to migrations folder in Domain but now since Domain has no dependencies, I have no access to my context (it is in a higher layer, therefore that would violate onion architecture rules (dependencies can't go outwards)).

  • Should I move my migrations folder to repository ?
  • Should I enable-migrations in repository ?
  • My configuration.cs file is very thin, is it mandatory to keep it (it does keep AutomaticMigrationsEnabled to false which makes me doubt this, seems like something lazy to do but who knows)?

Thanks for help!

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Flexabust Bergson
  • 732
  • 14
  • 34

1 Answers1

1

The domain should be with as few dependencies as possible, so you can:

  • Create a new project and move there only the context and enable-migrations on this project. By doing this you can decouple the repositories from the context.
  • Leave as is, and use enable-migrations in the repository project, just as you said.

I'm using the first choice in my onion-architecture project.

Mihail Stancescu
  • 4,088
  • 1
  • 16
  • 21