13

When you have a ton of business logic in one of the main services. Good or bad?

Comments
  • 1
    Looks confusing...
  • 6
    More like dependency nightmare! 😱
  • 1
    @lotd I am injecting various repositories into my service layer. What you see are private variables. I inject the repo's in the constructor of the service.
  • 2
    @appmaker
    I get that... but my question is what the hell does this service do that it requires you to inject 17 Repos, 2 other services and a mapping engine?
  • 1
    @GinjaNinja the service has a bunch of business logic seperated out to different methods where it needs these repositories to get data from their respective entities.
  • 2
    @appmaker I know. I just wanted to point out it looks confusing which should be a fairly telltale sign...
  • 2
    @appmaker
    Another burning question I have is...
    What the hell does IMiscService do? 😖
  • 2
    @appmaker how I generally set up my services is I only give them the repository they are responsible for. All the other stuff you talk to the services.

    So in that case I would not inject the UserRepository into the CourierService but the UserService instead.

    Idk if this method would cut down on dependencies for you?

    Also, if you can identify an unrelated responsibility (like parsing some data) in your CourierService you could consider creating a service from that.
  • 1
    What's with the _?
  • 3
    Looks like SDD (Service Driven Design). You should seriously look at the ideas of Domain Driven Design here. Business logic in services is considered bad for so many reasons...
  • 1
    @serpent5 depends I guess? Dunno but guess these are sort Amazon microservices?
  • 1
    @bendr but the lowercase name should already mean it's private. Otherwise it would be a Property
  • 0
  • 0
    @bendr Guess it's just syntax... Perhaps he's a C++ guy mostly.
  • 1
    Three words: Unit of work!
  • 2
    For some reason i cant post my comment. So i attached a pic of what I wanted to write lol
  • 1
    I think this would be solved using a Repository Context, that way you only inject the context and all the possibly needed repositories would be available and usually services are not dependent of each other, you might be implementing bad the layered architecture, if this sounds somewhere right or not please tag me.
  • 1
    @billgates I don't know if the question has been answered but that convention is what I use for read-only variables
  • 2
    That's a pretty busy-looking service you have there. We have a general rule-of-thumb where I work: If you are injecting more than 5 dependencies into your services, it probably should be broken apart or refactored.

    It has served us fairly well over the past couple years. We've gone back in some instances and cleaned up some pretty coupled code.
Add Comment