Reputation
2,235
Top tag
Next privilege 2,500 Rep.
Create tag synonyms
Badges
5 17
Newest
 Custodian
Impact
~16k people reached

  • 0 posts edited
  • 40 helpful flags
  • 9 votes cast
Aug
29
answered Event Sourcing , sagas, bus and eventual consistency
Aug
19
comment Persisting Large/Complex Entities with the Command Pattern — Am I doing it right?
Well, you could pass the request around and simply get the values from there but that would be a VERY bad idea. It's just the little overhead that sometimes comes from awesome code you're dealing with I'm afraid:)
Aug
19
comment Persisting Large/Complex Entities with the Command Pattern — Am I doing it right?
In that case, you do need an ID to query for that object again. But since that ID now has business meaning (it is different from the primary key in your database!) I would probably have the controller map the request-fields AND use some kind of service-class to fetch a new id (an UUID works fine, they're virtually guaranteed to be unique) and put that into the command as well. You can handle the command which persists a new order with the UUID you passed and you can get it back from the repository.
Aug
19
comment Restful User/Password Authentication
Could be a matter of terminology. 'Token' in this context explicitly means not bound to the server in any way, session id means the server itself stores information on the ID. Think tokens in a REST API which do not reside on the server and have to keep their timeout information embedded in themselves and PHP SessionID's which are often stored on the server that started the session and for which timeouts are stored there.
Aug
19
comment Persisting Large/Complex Entities with the Command Pattern — Am I doing it right?
Could you clarify "I'm pulling the same data as I pulled from the Request object back in the Controller, now I'm just getting the same data out of the Command object. Seems repetitive..."? You are pulling data from the command into an domain object. Would you say that a ChangeEmailCommand where the email is pulled from the request into the command and later from the command into user.ChangeEmailTo()-method is repetitive? Or is it just the fact that for this one example you have a lot of data on the request to put into the command and then into the domain object?
Aug
19
answered Persisting Large/Complex Entities with the Command Pattern — Am I doing it right?
Aug
19
reviewed Reviewed Best approach to setting up test and production environments for a new project
Aug
19
reviewed Reviewed Persisting Large/Complex Entities with the Command Pattern — Am I doing it right?
Aug
19
answered Testing async code: are long sleeps acceptable?
Aug
19
answered Restful User/Password Authentication
Aug
19
answered Unit Testing without DI
Aug
17
answered Usage - Factory Pattern vs Dependency Injection
Aug
15
comment Inject or not dependencies in a component based framework
Yes, you can do that.
Aug
14
answered Inject or not dependencies in a component based framework
Aug
13
reviewed No Action Needed Is using object of main class better than using static main method?
Aug
12
comment How to avoid using service location when using dependency injection?
You've hit the obvious snag where every change means piling more dependencies onto a constructor. We've all been there. Keep at it. Evolve to designs that have small classes with few arguments in the constructor. Keep your classes open for extension and closed for modification. Look into SOLID.
Aug
12
comment How to avoid using service location when using dependency injection?
IoC is about managing big chains of dependent objects and there is very little benefit in DI just for the sake of it. DI and TDD work well together because they tend to evolve an architecture towards small, single-responsible and generally SOLID objects. What do YOU expect to gain from using DI in the first place?
Aug
12
comment How to avoid using service location when using dependency injection?
Not really as some things can (and should) be resolved dynamically. For example, you can have a CommandHandler class that takes a command, from the type of command gets a <CertainTypeOfCommand>Executor via IoC and hands the command of to that. CommandHandler would take an IList of ICommandExecutors in the constructor, NOT have a constructor that takes every single Executor hardcoded. Adding more Executor-classes does not mean you add to the constructor.
Aug
12
revised How to avoid using service location when using dependency injection?
added 468 characters in body
Aug
12
revised How to avoid using service location when using dependency injection?
added 468 characters in body