5

Think that when one Branch saved, a Customer entity must created in n tier layered system architecture. All validation has already implemented in CustomerService.

  1. Should BranchService create CustomerService instance to create customer?
  2. Branch service implement validation again for Customer and call CustomerRepository?
  3. Branch must have Customer entity as a propery and should have Customer validation on BranchService?

Sample Classes are

Branch
    - Code
    - Description
    - CustomerId


Customer
    - Code
    - Description
    - CustomerType

BranchRepository
    - Add
    - Remove
    - Get

CustomerRepository
    - Add
    - Remove
    - Get

BranchService
    - AddBranch (Validates entities)

CustomerService 
    - AddCustomer (Validates entites)
hkutluay
  • 153
  • 5
  • Could you clarify what you mean by "service", "repository" and "branch"? I would guess that you're using a framework where "service" and "repository" has a standardized meaning, and that these are bank branches not version control branches, but it's important that we don't guess wrong. – Ixrec Mar 11 '16 at 10:43
  • 1
    @Ixrec Actually it is common patterns in n-tier application design. Please find implementation on http://chsakell.com/2015/02/15/asp-net-mvc-solution-architecture-best-practices/ – hkutluay Mar 11 '16 at 11:33
  • 2
    Ick, that link advocates using Generic Repositories in a very bad way. Generic Repositories are a neat convenience when hidden behind a Concrete Repository. However, if your Concrete Repository exposes your Generic Repository you now have a leaky abstraction. It forces the repository *Callers* to take care of all the querying logic. This is bad because the Repository should be hiding the querying concerns from the rest of the application. – MetaFight Mar 11 '16 at 11:47
  • The link in your comment uses Entity Framework, in which case the repository pattern is pretty much redundant; have a look at this answer: http://softwareengineering.stackexchange.com/a/220126 – Ben Cottrell Apr 09 '17 at 13:14

2 Answers2

1

Don't concentrate so much on making entity specific services, but use case specific services.

Your code should reflect your business logic and processes and their use cases. If you have a use case that says that customer and branch should be committed together, then create such a service.

Create a CustomerBranch service that would encompass both the customer and branch. You can store validation in entities themselves, or in a separate service. It's up to you. Or you can inject your current services into this one where you'll use their validation logic.

Then you can use the Unit of work pattern where you use your repositories to just "notify" ORM that there is a change in an entity, and UoW to Commit those changes to DB. UoW pattern enables you (among other things) to commit batches of changed entities.

Repository pattern, as it is advocated throughout the Internet (in my opinion wrong, but that's another subject), concentrates on changes from one entity only.

civan
  • 479
  • 2
  • 7
0

  1. There are two patterns which can solve this problem. i) Use repository pattern to design data layer. Reference - http://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/ ii) Unit of work https://dzone.com/articles/generic-repository-and-ddd-rev

  2. Use run time serialization over objects using libraries available(Jackson - one of best available out there)

  3. Service end points seems correct to me however I would suggest keep reference object of Customer inside branch class.

  4. Allow service to accept the Json instead of qualified objects. This is where step 2 is handy.

  5. (additional) rest on spring handles step 2 and 4 quite elegantly. Reference - http://www.mkyong.com/spring-mvc/spring-3-mvc-and-json-example/

I assume you are building the solution using Java. Hope that helps.

Deepak Patil
  • 29
  • 1