What you think about business logic

1. Do not involve too many data tables in one operation, too many data tables---lead to complex coding, error-prone, so that is a way to do a lot of things

2. Business rules correspond to business methods

3. Now look at the data, everything we see on the page is data, so how do you abstract that data into the object you want?

4. Let go of your mind, you can create any object, no right or wrong, in your world you are the master, you want to how to operate the operation of the
So please do not restrain your thoughts, and build up the world of what you think you are.

5. To have a concept of "user interaction" "Use Scene" "Interactive process", in this analysis of interaction can see a lot of problems

6. We need to get out of the data access layer, directly in the business layer, in the system to look at business objects, do not make the design of the database affect our implementation of the system

7. You cannot determine your business object based on the database model, and what you want to use in your business is entirely a business-specific decision.

8. The original architecture is for business logic

9. Business logic determines your database design, it is a top-level thing

10. You can infer your system business logic from the database

11. Database design is a low-level thing, belong to the business logic, do not cart before the horse

12. To learn to draw the system object Business interaction diagram

13. The Table object in the database is not equal to the business object this note

14.VO and DTOs are pretty much the same thing.

15. The so-called ORM is actually modeling objects in the database and putting them in the program object to use

16. The message model of object interaction is a more essential feature of OOP

17. The message is concerned with the interface and interaction between objects, and when building large systems, it is not the internal state of objects/modules, but their interactions

18. Encapsulation is the separation of class-based static code boundaries, so that the private code modification of the class does not affect the outside world, rather than the protection of dynamic objects

19. Some common entity classifications and product branding and classification

20. We can focus on some of the Microsoft internal Class object encapsulation process, I think these masters of the design should be very smart

21. And the use of the locomotive is a reason, should be more to use, in order to flexible to work together

22. Define your object as needed

What you think about business logic