L2J Server

Trying to improve L2J architecture, testability and overall design I have been experimenting with dependency injection in the core.

https://bitbucket.org/l2jserver/l2j-ser ... e6f2ec3cbd

I've used Spring Context (could have used Guice, but I may use more of the Spring Framework in the future), the basic idea is to create managed beans and avoid Singleton anti-pattern that we have favored so much in the past.

In this example server is configured to use a new application context and all DAOs are turned into injectable @Repository beans, also player loading and creation is segregated to a PlayerService class.

This @Autowire(d) components are not visible in datapack due compilation, need to experiment with AspectJ a little bit further to get it working.

Before moving forward on this approach, I'll work more on completing this DAO/Repository classes removing data access code from classes such as L2PcInstance.

I'd like to know what do you think about this approach, I believe it could help go towards TDD and more flexible and extensible Core implementation.

Some of these injections look like they'd reduce CPU usage and speed of access (`DAOFactory.getInstance().getXDAO()`) and, conversely, potentially slightly increase memory usage due to persistent in-memory references that these calls avoided. No idea which is better, but I'd probably go for reduced CPU usage since RAM is cheap and plentiful these days.
However, some seem to be pointless (injecting an instance of a class when only static methods of that class are used). That's essentially an unused instance.

jurchiks wrote: ↑Mon May 04, 2020 12:26 am Some of these injections look like they'd reduce CPU usage and speed of access (`DAOFactory.getInstance().getXDAO()`) and, conversely, potentially slightly increase memory usage due to persistent in-memory references that these calls avoided. No idea which is better, but I'd probably go for reduced CPU usage since RAM is cheap and plentiful these days.
However, some seem to be pointless (injecting an instance of a class when only static methods of that class are used). That's essentially an unused instance.

Agreed, that not all would benefit right away, this is not really about CPU or RAM, it's about design and extensibility, you can neglect most of this injection costs.

I was using DI with PHP which is also awesome to decouple for testing. Sounds great.

Great work! Keep it coming

Although this is an old thread I must say that adding DI is a big step forward. Specially if you aim for TDD. I honestly don't know how you can test the code now.

Aside from TDD, you could also be interested in DDD. I think it could be pretty good for this kind of complex projects.

Hi,

A few of these infusions see like they'd decrease CPU utilization and speed of get to alternately, possibly somewhat increment memory utilization due to diligent in-memory references that these calls dodged. No thought which is superior, but I'd likely go for diminished CPU utilization since Slam is cheap and ample these days. However, a few appear to be inconsequential (infusing an occasion of a lesson when as it were inactive strategies of that course are utilized). That's basically an unused occurrence.thanks! i am working on furniture.