Hi, > On Dec 30, 2015, at 2:46 PM, Jürgen Simon <[email protected]> wrote: > > Absolutely. Proper DI facilities make things a lot easier to test. And the > code much cleaner. Wouldn’t it be nice to have something like > > @Autowired > EOEditingContext editingContext;
No. Because now you have no clue where and how that editing context is being created. You literally have to search the entire code base to know the answer to that question. Or, let me correct myself, even then you’re not sure because runtime may be different. On the other hand, if you have ERXEC.newEditingContext(), you *know* what code is running to create that EC. And if you have access to the code (and in Wonder, you do), you can even read it, not just rely on the documentation. The reasons I hate DI frameworks like that are: - It makes reading (and thus understanding) the code spectacularly hard. Hard to the point you may spend several hours trying to figure out what object was created and injected and why that object is not the one you expected to be. Keep in mind that in things like @Named the object can be created anywhere in the code base. Also keep in mind that some DI frameworks, like Spring, when faced with two objects in the class path for the same @Named name, will silently pick one trough some arbitrary criteria, instead of crashing and burning, AS THEY SHOULD DO BY DEFAULT (I know they can be configured to to that, but the default behaviour is not the safe behaviour which is stupid). - You have absolutely no way to know for sure what object is going to be inserted unless you run the app and check it. And obviously the results of doing this in your developer environment can be different from the ones in a production environment. How in the world can anyone think this is a good idea? You can argue that anything in Java has the same behaviour, what class you get depends on the class path you have on the runtime. However, this is a side effect of how Java was designed, and one that causes much headache and is one of the major complains about the Java platform (class path issues). DI is like this *by design*. It incorporates in its design something that is widely recognized as a major problem of the platform. - I think that if you have to mess up your code to the point of not being able to know (mathematically speaking) how it works unless you run it in order to make your code testable, you’re doing it wrong. If you need indirections to give you different objects when running and testing, then make those explicit in the code, and add them only on the places where you really need it. - It’s one more thing to deal with, configure, work around the limitations and bugs, etc. And the very last thing software development needs is more of that. Overall, it seems like an extremely inelegant and complex solution to the testing problem. That problem is not easy to solve, it’s true, but I think overall DI brings more pain than gain. Regards, Miguel Arroz > instead of > > EOEditingContext editingContext = ERXEC.newEditingContext() > > perhaps even with some rule based setup, aka: D2W meets DI? > > Just thinking out loud. > > J. > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/arroz%40guiamac.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
