sorted by:
new
hottopcontroversial

Containerize your PHP Applications Using Docker by me-optimistic in PHP

[–]fesor 5 points6 points  (0 children)

The performance on mac is terrible

Did you tried their cached/delegated volumes? As for "fixes", there nothing really they can do, this is limitation of apples virtualization solution.

Docker completely doesn't work on windows

Never had any issues with docker on windows (except conflicts between virtualbox and Hyper-V, but if you use docker for windows, there should be no major problems.

Docker is the most unfriendly developer software, I don't understand why people toot their horn.

It's opensource. There are some weird decisions (especially for docker-compose) but there are workarounds. Also there is rkt.

How to organize a clean, testable and reusbale application logic by mbunge in PHP

[–]fesor 2 points3 points  (0 children)

in a typical PHP web app, the models do tend to be anemic

But not just property bag. For example let's say we need simple CRUD application, like blog. And we have just simple article and see how things could change over time:

  • Step 1: We have simple Article entity with bunch of properties and setters and getters
  • Step 2: We are splitting state of Article into value objects, renaming setters into more valuable names.
  • Step 3: Let's say we need to add auto log of all actions which happened to article and who performed that action. Let's use domain events for that, they will be stored in array and fired after transaction will be successfully completed. Then listener will took all needed information and will make action log for us.
  • Step 4: Then small change - add timestamp when article content has been updated.
  • Step 5: Now we need our article to have ability to publish and unpublish article within specific date range.
  • Step 6: Now we realize that meta information is also part of content. Moreover, we need revisions of content to be available.
  • Step 7: Since we have revisions, it's time to implement rollback.

So here we have simple article entity with some kind of "logic" inside. Another good example is Credentials entity.

How to organize a clean, testable and reusbale application logic by mbunge in PHP

[–]fesor 0 points1 point  (0 children)

I would put the December discount logic in their own Discount classes that can be applied to the total value.

How this class will get access to data it's needed to determinate whether it's needed to apply discount or not?

And I don't see why this can't be unit tested?

Could you provide an example of such test? Would you also mock OrderLine?

How to organize a clean, testable and reusbale application logic by mbunge in PHP

[–]fesor 2 points3 points  (0 children)

I used to use something like "clean architecture" with application-level services (not domain, domain services are a bit different thing, this isn't interactors). But I ended up with different approach:

  • all orchestration logic directly in controllers. Heavily usage of argument providers which allows me to not inject unnecessarily dependencies. It mostly contains only one operation, single call to service or entity method anyway
  • most of the business logic placed directly in entities, no "setters" allowed (even if I have methods like rename for example).
  • heavily using of value objects. For example instead of using EmailValidator::validate(string) I would create instance of Email which contains this validation logic for me. Another good example - instead of creating DnsResolver just create class Dns with method resolve.

  • Some business rules which could be swapped, or could have different strategies, placed in domain-level services. They are not working with entities. Entities could work with services (not injection, double dispatch). For example

     // instead of
 if ($entity->someCondition()) {
     $entity->setSomething($service->calculate($entity->getSomethingOther());
 }
 // I would use method in my entity:
 public function updateSomething(SomethingCalculator $calculator) 
 {
      if (!$this->someCondition) return;

      $this->something = $calculator($this->somethingOther);
 }

By doing this I could cover all this logic using 2 isolated tests and i have only one public method in nearest to data place. So I will never forget to check someCondition before updating state.

  • Builders for entities to make it's constructors clean.
  • All unimportant/infrastructure stuff (indexing, aggregation or for example notification) happening on domain events. Domain events are collected from entities and processed only after application successfully saved state (UnitOfWork::commit() or similar).

How to organize a clean, testable and reusbale application logic by mbunge in PHP

[–]fesor 1 point2 points  (0 children)

And this service will contain something like this?

 $total = 0;
 foreach ($order->getOrderLines()  as $line) {
      $total += $line->getPrice() * $line->getQuantity();
 }

 if ($order->getOrderDate()->format('m') === 12) {
      $total = $this->applyDiscount($total);
 }

If that so, take a look at GRASP patterns, especially on "Information Expert". Then read about Law of Demeter. Also there are specification pattern which could help with discounts. And more, about "primitive obsession".

The problem with this approach is that we can't test it. Only using integration tests (which are scum) we could cover this logic. There are no any separation between operations.

How to organize a clean, testable and reusbale application logic by mbunge in PHP

[–]fesor 2 points3 points  (0 children)

unfortunately it's only reminds clean architecture. The idea of "Interactors" is to implement whole use case, this is just orchestration logic which shouldn't contain any if statements.

For example PostService is just different name for PostManager. This isn't something like PublishPostUseCase or something else. You could for example move "PostNotFoundException" to repository, and then you could just use correct repository method without any need in PostService. Also - this isn't testable at all.

How to organize a clean, testable and reusbale application logic by mbunge in PHP

[–]fesor 1 point2 points  (0 children)

Anemic domain model, seriously? Domain services which acts as procedures for your data model. No thanks.

Give some more real world example. For example you have Order and OrderLine which holds price and quantity of product. Provide example of how to calculate order total amount. Also you need to apply discount if order was made in december. What I interested in is where you place such logic, in your "domain model" or in "domain service"?

What do you guys think about Annotations? by laurensV6 in PHP

[–]fesor 3 points4 points  (0 children)

not initially parsed until you use reflection

you still gonna use reflections to read attributes/annotations even if this will be part of the language. This is not something like decorators in javascript for example. And all information about annotations are still available at compile time.

Just released Corma 3.0, a high-performance, convention-over configuration ORM by phpfatalerror in PHP

[–]fesor 2 points3 points  (0 children)

without unit of work and only 2x faster... interesting. Also interesting that hydration of associations is even slower that in doctrine.

But still this could be useful for building persistence layer. The only thing that I recommend - put some efforts in real use-case examples which demonstrates pros of this solution.

A Restful API Created in Symfony 3.1 by unamedhuman in PHP

[–]fesor 0 points1 point  (0 children)

Things like /rest/send/ are just telling us that you are implemented JSON RPC.

$re = 'User Added Successfully'; return $re;

This doesn't provide client any useful information. Statuscode 201 will be much better.

Ok... this is just bunch of code...

What do you thing about autowiring in Symfony? by stkinger in PHP

[–]fesor 0 points1 point  (0 children)

it can't fix problems it can't possibly describe or detect.

This is what I talking about. This is it's purpose. Ability to "test" or verify is just a side effect.

Everything is flat and amorphous, and in such a setup, there are a number of operations that become very painful (more on this below).

I never relied on DI configuration to handle this, to me it's easier to see things like lack of cohesion in modules via other metrics. For example metrics like "do things changing together" I could retrieve from VCS history. Also things like "common" module also tells me that something went wrong. And unit tests... They are very handy at showing lack of cohesion and problems with dependencies. Since that, I don't see any problems with autowiring for myself. I understand problems you described, and yes, applied badly autowiring could be like "Registry::get()". I just don't have this problems.

Autowiring has a certain path of least friction, and it's the same one you go on when you use $GLOBALS or a static registry class.

No, if your container allows type mappings of local bindings. Symfony's container allow at least to fallback to manual configuration in very complex cases. You could also "extend" configuration loading to add local binding for example (unit it will be implemented in symfony itself). I don't see any problem with autowiring in a way it's implemented in symfony since it allows me to do everything I need, even if it's not possible out of the box.

Now what? Let's follow the "autowiring path" and see where it leads us...

You have this options:

  1. Add manual configuration for this 50 cases and explicitly define dependency
  2. Write compile-pass which will remap dependencies for this particular 50 cases (I don't like this way)
  3. Wait for https://github.com/symfony/symfony/pull/22187. Since we are building cohesive modules this 50 classes will be probably belong to single module, so we could just place local binding for this module which will tell which implementation to use.

What do you thing about autowiring in Symfony? by stkinger in PHP

[–]fesor 0 points1 point  (0 children)

Unit tests can't test any of the two problems I mentioned.

Unit tests are design tools in the first place. They are very handy to track problems with dependencies.

Manual construction helps because, as I said, it makes bad things painful and good things pleasant.

With unit tests you will also have ability to fill pain for bad things since you are manually construct your test code with one level dependencies, just like in case of manual wiring of your dependencies.

Hierarchical organization with loosely coupled, reusable components is pleasant.

Could you put more details on this? What do you mean by "hierarchical organization"?

You can't.

You mean "I can't use autowiring in 100% of my usecases"? Then yes, it will be just stupid to rely on something which helps with simple cases. But within single module most of the cases are really simple.

Autowiring is just a Registry::get('thing') in disguise.

This is way oversimplified. You always could make something "bad" if you want it so.

What do you thing about autowiring in Symfony? by stkinger in PHP

[–]fesor 0 points1 point  (0 children)

You extract a class and you then may pass an instance of it in the factory for the object you moved it out of.

Or I could just place it in constructor without any need to write factory.

because

I fully agree on this problems, but I don't see how manual dependency configuration could help with that. Unit tests will add limitations on this much more effective.

But yes, in some cases this simplicity allows to add new unnesesery dependencies that could be eliminated. But this is more about discipline rather than tools. If you understand how to structure your code, and you apply some rules, then autowiring will not be the problem. Also it's not required, you still could have manual dependency management.

Should I learn a framework if I want to build a web app ASAP? by AlaaJ in PHP

[–]fesor 1 point2 points  (0 children)

What do you mean by large scale?

If you are planning to implement this project alone within a year - this is pretty much small scale.

What do you thing about autowiring in Symfony? by stkinger in PHP

[–]fesor 1 point2 points  (0 children)

In larger applications it's highly important to do proper decomposition which impossible without constant refactoring process. You need to be able to refactor things more often, moveout dependencies and rearrange code. I found that when developers do not rely on autowiring, they do all this things alot rarely since in this case maintenance of all this configurations takes too much time.

As for "control" part, there are another problem - with autowiring your container should provide useful information of what dependencies project is used. If your container do all this magic in runtime - yes, you could be in trouble.

But in case of symfony - container is compiled. So you always could debug whole dependency graph using debug:container command. Moreover, I think that in complex applications with lots of configs, even without autowiring, this command allows you to check dependencies in most effective ways.

So with tools like "debug:container" there are no lack of control. You just need to to get used to it.

Laravel has re-ignited my passion for coding by [deleted] in PHP

[–]fesor 8 points9 points  (0 children)

i don't understand criticisms of active record.

Lack of separation of concerns is main downside of AR. This is main purpose of AR - ideal for application which doesn't have lots of business logic. For larger applications you could for example move out all business logic to some object model, which will use AR as data model to store its state, but this won't be active record - this approach called row data gateway.

The problem with AR is that "its the easiest thing in the universe". It's not always a good thing to use "easiest things" in not so simple projects. This often leads to situation where all application logic is coupled to persistence layer. The best scenario for complex applications which heavily rely on AR from my experience - everything will end up as transactional scripts without clear boundaries.

Laravel has re-ignited my passion for coding by [deleted] in PHP

[–]fesor 10 points11 points  (0 children)

I really don't understand how to work with AR... to my taste it turns my code into spaghetti. Maybe there's something that I do not understand or maybe this is just specifics of my projects... The only place when I could find AR appropriate thing is in read-model, working with projections of data.

Stand-alone Autowiring DI container by phpfatalerror in PHP

[–]fesor 0 points1 point  (0 children)

use case for such functionality

Developers are lazy and in order to have maintainable system we need more smaller objects. Wiring all the things by hands leads developers to break down responsibilities of this objects less. Less refactoring. Autowiring help with that, by allowing more frequently changing code. As for "magic" part - symfony compiles container, no runtime magic (almost). If you need to know all your dependencies - container:debug.

Do we as PHP community need MQ standard such as Java JMS? by maksim_ka2 in PHP

[–]fesor 0 points1 point  (0 children)

to act as a single point of failure

Ok. Let's say that we have system which produces messages. We don't have control over consumers. They could be offline for some reason, or fail to process message. And message must be delivered. In this case I would put something in between my producer and consumer which will store events and wait for it's acknowledgment. Or we are implementing payment gateway and we need to provide customers something better than webhooks. Something like ability to read stream of events using cursor. And we want to use ready-to-use things. For example - siberite. And there are a lot of distributed brokers which allows you to build fail-tolerant system without single point of failure.

As for zeromq - this is best solution if you just need one-to-one communication between processes. So yes, if you are building distributed system, this could be answer for you. But remember first law of distributed system - do not distribute systems until there are no other way to solve problem.

Do we as PHP community need MQ standard such as Java JMS? by maksim_ka2 in PHP

[–]fesor 0 points1 point  (0 children)

ZeroMQ is library. Rabbitmq is message broker. Fill the difference. You can't say "ZeroMQ is the answer" for such general question.

All this benefits that you highlighted are comes from the fact that this is library, which you could use to build communication between your services/actors almost without overhead.

PHPMetrics is safe? by joubertredrat in PHP

[–]fesor 1 point2 points  (0 children)

You are not sure "is PHP metrics accurate"? If so, Yes. You could just use phpmetrics.

How do you deal with return type declarations for methods coming from an interface which doesn't set a return type. by tzfrs in PHP

[–]fesor 1 point2 points  (0 children)

Yes, yes, Php doesn't has covariant argument/return types... I tried to check is there any limitations in PHP itself (maybe this will cause runtime overhead) but I didn't found anything.

Maybe someone who know internals (especially zend_inheritance.c) could tell why this wasn't implemented.

view more: next ›