1

I have the Customer entity, this entity has a huge list of attributes, so you are thinking in separate in small entities (for example: "basic info", "document", "declarations", etc). This approach will be used in the view layer, where the user can fill your info, step by step, making possible stop and comeback later. But I'm no sure if make sense to reflect this fragmentation in others layers. Because, we will have a lot of controllers in client and server side (since we are using express.js and angular.js).

Follows an overview of the complexity in terms of fields, remembering each "partial" must be valid and once valid, it is saved in the database:

- info for generate the customer
  -- name
  -- email
- basic info
  -- dob
  -- gender
  -- hometown
  -- state
  -- country
- phone info (just one phone)
  -- prefix
  -- phone number
- bank info (can be more than one)
  -- bank
  -- agency
  -- account number
- etc

Any suggestions?

1 Answer 1

2

This depends on how your customer entity is processed in those other layers. If you only store that data in a table with an even huge list of attributes, it won't make sense to split the entity into parts. But if your controllers contain some business logic for customers, I guess they will probably have processing steps with smaller customer parts either. So a separation would make sense at that layer, too.

1
  • The business logic will be only in the entity (model), that will be compound of many validators. Controllers will initialize the model with the params from the current step, and then call customer.validate. Thanks for the answer!
    – Fabrício
    Commented Feb 6, 2014 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.