better third-party framework and business logic separated from the framework.

a source

Examples are not necessary, just explanations, how can one be separated from the other? The logic of the dependency framework

Please do not minus - and explain

Closed due to the fact that the essence of the question is not clear to the participants of user33274, Kromster , Streletz , rjhdby , aleksandr barakin October 13 '16 at 10:17 .

Try to write more detailed questions. To get an answer, explain what exactly you see the problem, how to reproduce it, what you want to get as a result, etc. Give an example that clearly demonstrates the problem. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • 2
    Why not ask the author of the answer directly what he had in mind? Was the toaster registration free? - Ipatiev
  • @ Ipatiev damn I trust more of the public here - than a toaster - user33274
  • It's not about trust. Here is a question about what a particular individual thinks there. And there are no more telepaths here than on a toaster. - Ipatiev
  • @ Ipatyev you are like php - probably understand what it is about? For example, php is not my fad, but when it comes to photoshop or corel draw or css3 or hz I still understand what - user33274
  • No, I did not understand. And php has nothing to do with this - a similar question is related to any language. For me, this phrase - oil. 100% of projects are written as written there. I have no idea how to do the opposite - to shove business logic into the framework. - Ipatiev

3 answers 3

Business logic is actually the logic of your application. A framework is a collection of libraries that performs standard routine operations.

For example, if you are writing an application for a public bath, then the business logic will contain a description of the user profile, schedule, search for free places for booking, etc. At the same time, it can use the framework for such things as communicating with the database, working with query parameters, dependency injection, working with mail, etc.

    It is wrong to use the concept of “ better ” here (it looks like imposing personal interests), in some case it will be more correct to write your crutches, in some way to use the framework. There are certain reasons for this or that case, this is a matter of taste of each team and requirements for the task , we will not dwell on this.

    The concept of separated business logic is based on reducing connectivity. This is the principle of designing a multi-tier architecture, in which you communicate with the framework components via interfaces, thereby making your project independent of the use of third-party software. Nobody says that the framework will change easily when using interfaces, but it will be easier to do than without them.

    Suppose we have a DI container embedded in the framework, you can directly use it, or by implementing your own services to abstract certain services, and suppose when you install the new version of the framework, and it will change the method of obtaining c $di->getService("myservice") on $di->get("myservice") you will only need to make a change in your class ( for example, ApplicationContext). You will hardly change your interface, and third-party software developers can come to the new convention of naming.

    Business logic should be on the same level, the framework and third-party libraries on the other. This is an ideal architecture and deviations from this architecture will be, because the implementation of abstractions and their support for new tasks requires a decent time, but this should be strived to easily replace any components and reduce connectivity, but fanaticism is not needed here.

    An example of such a design is the onion architecture, the hexagonal architecture, and any normal layer-based architecture.

    Layered architecture

      It is very simple to implement business logic on simple PHP classes (POPO - Plain Old PHP Object) that are completely independent of the framework. You just need to understand what is business logic, and what is the logic of the application. Business logic operates with concepts of the subject area, for example, in the case of a store, these are the concepts of "buyer", "product", "order", "account", etc., in the case of playing "character", "inventory", "map", etc. Business logic knows nothing about databases (unless of course you are developing something like phpmyadmin), files, controllers and views, it doesn’t know how its entities are stored, for it ideally they live in memory forever, until she decides to remove them forever.

      Frequently used framework doesn’t allow the business logic to completely get rid of dependencies on the framework, for example, forcing it to write something like the class Order extends Model to ensure that the order is saved in the database, then you need to abstract as much as possible from this fact - inherited and forgotten ( within this class and other business logic classes) that there are methods of the type save or delete - only the controller should call them (in MVC terms), but not business logic.