3

So.. I was working lately with onion architecture and also been reading quite a lot about it, the only thing that most of blog posts/guide/etc. did not explained is, where do I keep logic like upload of image or some calculations?

Right now I got something like this

-app.core <-- keeps the domain models and interfaces for repository with simple add,update,remove, get, getAll things

-app.infrastructure <-- implements my app.core repository and also has services, contains the IoC modules and mappersettings

-app.application <- it just all about users that makes request to the controllers and the controllers calling the services from app.infrastructure and gets back DTO models

So.. where do I put those two things? Because I feel like all onion does is is add,update,remove,get,getAll

Where do I keep more complex code.. like file uploading? halp

bunakawaka
  • 535
  • 6
  • 14

2 Answers2

4

Your domain (or core) doesn't have to be logicless. In fact, I'd say that your business logic SHOULD be in your domain, as your business logic is the core of your application. It's what actually gives your business value. I'd put that logic there. While you're writing that logic, you might notice that you'll need to certain infrastructure calls to save to a file system or send emails. You then just add the interfaces to your core, and assume that it'd be implemented (and injected in) by an outer layer.

Carlos Rodriguez
  • 2,190
  • 2
  • 18
  • 29
  • so do you think it is a good idea to make something like IPhotoSaverService and make a repository in app.core like IPhotoSaverRepository that instead of lets says makes a database calls it saves images to directory? – bunakawaka Jul 12 '17 at 19:39
  • To be clear, the interfaces should be in core. The actual implementations shouldn't – Carlos Rodriguez Jul 12 '17 at 19:41
  • Yeah, all of my implementations are for core interface are placed in infrastructure layer. So, saving files in PhotoSaverRepository is a good idea? Thanks for helping anyway @_ @ – bunakawaka Jul 12 '17 at 20:25
  • Yeah, that makes sense to me, assuming that the PhotoSaverRepository is a class in your infrastructure layer, and it's implementing the IPhotoSaverRepository interface which was defined in your core library. – Carlos Rodriguez Jul 12 '17 at 20:29
  • 1
    Yeah, that is how I had it until now. Just like all operations were based on those basic add/delete/remove/get and then when I found out about implementing file upload, I was like "Where the hell am I suppose to do that?" – bunakawaka Jul 12 '17 at 20:34
  • Ah I see. So ideally, your core app uses IPhotoSaverRepository. It doesn't care about the specifics about how the photos are saved. The actual implementation details are left to your infrastructure layer. It's a good practice because, let's say you have a LocalPhotoSaverRepository which just saves your photos locally. Later on, you want to move your photos to the cloud. You can then just make a CloudPhotoSaverRepository that also implements the same interface, and your domain (core) wouldn't ever know the difference. – Carlos Rodriguez Jul 12 '17 at 20:38
0

I'd piut it in app.core if this feature is shared between layer

Laurent Morissette
  • 46
  • 1
  • 6