Middle Ground between 'Newable' and 'Injectable'?

As noted previously, Misko Hevery asserts that every objects should be either an "injectable" or a "newable."

The question is: why does then Spring support prototype scoped objects which can be injected with well injectables? The condensed and recently supported alternative (through this initiative) to creating a prototype scope object -- which requires access to the ApplicationContext through ApplicationContextAware or BeanFactoryaware (not good* because it becomes a Service Locator "DI Catch 22") -- i.e. the @Lookup or lookup-method with parameters supported is really just syntactic sugar for a prototype scope object, IMO.

On the other hand, the fact that Spring does the wiring under the covers may make @Lookup-with-parameters okay. However, if one tried to do the same in code it would probably violate Misko's rule stating you should not inject an injectable into a newable, where the newable is the prototyped scoped object.


*Note: it may be more nuanced than black and white whether usage of an injected ApplicationContext is or is not good IoC. e.g. see comments by Alex Worden regarding enabling a sort of polymorphism where you "dynamically create new bean instances based on a bean name that is unknown at compile time but matches one of the implementations defined in my spring.xml file" - http://stackoverflow.com/questions/812415/why-is-springs-applicationcontext-getbean-considered-bad this might be a valid use of 'ContextAware. Commenters note that this is not really IoC but rather ordinary factory or Service Locator but pap notes that "Spring is about more than just IoC."

Similar question raised here.

Found this problem is similar to the question of how to do DI and the Command Pattern at the same time. Turns out they may be incompatible. see and see

DI - When to 'new'

Misko advises to keep "newables" separate from "injectables" - so newing things up are okay if they are value objects. http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

I go to that article via a comment in http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/  where he's emphatic about doing the DI. The "newable" exception is very important to consider. Specifically, a newable is an object a DI container would have NO WAY of know how to instantiate -- like a User() or PhoneNumber.

Continued...

Repository vs. Service

One issue causing confusion about whether to choose a repository or a service is where to put business logic methods like getEntityItemBySomeAttribute(attribute).

The use of Specifications in a standard query method seems to solve this problem.

Where you would want to choose the Service instead is when the logic of the query spans multiple repositories or a combination of repositories and external services -- this is DDD guidance.

Be mindful of the difference between APIs and SPIs. APIs should be final concrete classes and SPIs should be Interfaces. The clients of APIs are callers while the clients of SPIs are implementers.

I've noticed that repositories are typically SPIs while services are typically APIs.

Refs:
http://wiki.apidesign.org/index.php?title=APIvsSPI&useskin=monobook
https://docs.oracle.com/javase/tutorial/ext/basics/spi.html
http://stackoverflow.com/questions/12317126/onion-architecture-repository-vs-service
http://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/ -- notes that DAOs are no longer favored because they are too general and loosely typed.

-------
2015-09-03
Current common practice appears to have a topology like Service<T> --injected with--> Repository<T> --injected with--> JDBCTemplate or DataSource. see http://stackoverflow.com/a/24083073/2066936

CQRS and Architecture

lecture from several years ago. Items of interest are  

• an architecture graphic from 48:57 picturing both validation and business rules as components as opposed to layers
• the idea that a database ("persistent viewmodel") with viewmodel tables should replace the in-memory caches
• capturing the user's intent is not necessarily the same as editing a row in the database: "The fact that they are two columns on the same entity does not mean anything!"
• Example of user's intent is "reserve a block of seats on airplane for family/friends" but UI given is seats with checkboxes and a refresh button (to see what's changed to allow what they want)
• What are domain models for?
• "Domain models aren't for validation." Validation is there in its own component"
• see graphic from 48:57 and 1:29:38 where domain model is the "Rules" component
• validation component is actually the same one on the client-side and server-side (see graphic)
• Domain models aren't for queries.
• Domain models are for business rules: e.g. figuring out how much interest to charge once the user has violated terms of agreement and over-withdrawn their account despite the best-efforts of the client-side validation logic.
• Domain models are for doing what business people spend time on -- thinking of "adding weird ways to add functionality to the system to delight their customers" e.g. is it their birthday, should I send them a birthday present, is he a preferred customer, etc.
• "Client-side controllers [that are using the CQRS queries] are supposed to do [business] logic. It's not that big a deal"
• Quote on commands, that they must go through asynchronous messaging pipeline: "You need to design your commands such that you can say 'Thank you. Your email confirmation will arrive shortly."
• On Relationships
• "Once you've taken out all the relationships from your domain models they've actually become smaller and tighter -- focused really just on processing commands"
• And DTOs, ORM, etc. is removed from the query procesing and replaced with the one-table per view ViewModel (note points on search recommendations and removing ability to do complex queries from the user)

Quotes:
"Writing a custom form to accept: how many seats do you want? What kind of seats do you want? Trivial forms to write. Writing these query screens, now that you don't have to go through DTOs and domain models and object-relational mappers, and god-knows what else -- these are a lot of easier to write too! Once you've taken all these relationships from your domain models, they've also become quite a bit smaller and tighter focused really just on processing commands.

"Yes you do need to understand what your users are using the system for. Otherwise just give them access to your database and be done with it. "

"You can't shoehorn a CQRS architecture underneath an editable datagrid. Do not try. User interface design is as much a part of architecture as anything else that you do."

https://skillsmatter.com/skillscasts/1250-udi-dahan-command-query-responsibility-segregation#video

Domain Service vs Application Service

• If you follow Domain Driven principle, Order is a domain object but Email Sender maybe is a service ( different from Domain Service ) so you can’t use it in your model.

http://www.javacodegeeks.com/2013/08/how-to-use-events-in-spring-3-x.html

Other times I think of services as little classes that don't represent a particular person, place, or thing in my application, but that tend to embody processes. Domain services usually fall in this latter category. They tend to be named after verbs or business activities that domain experts introduce into the Ubiquitous Language

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx#id0090088 - goes on to describe in contrast how application services perform mapping between layers or other modules

From Singleton to AOP (And Everything in Between)

This article on game development touches on the nuances faced and the angst developers face when dealing with complex systems and still adhering to best practices ala IoC. The highest voted answer seems to favor neither the service locator pattern nor the singleton, but seems to lean toward dependency injection ("passing around the instances"). Nevertheless the OP appears to settle on Service Locator.
http://gamedev.stackexchange.com/questions/84197/how-can-i-avoid-having-many-singletons-in-my-game-architecture

An alternative to all three could be AOP as shown in this old article: http://blogs.msdn.com/b/simonince/archive/2008/06/30/dependency-injection-is-dead.aspx

But if you think that DI is hard, DI via AOP is certainly an order of magnitude harder -- which is probably why it's not spoken of much.

Private Inner / Local Classes - Advantages / Disadvantages

Good debate found here: http://stackoverflow.com/questions/3353318/how-do-i-test-local-inner-class-methods-in-java

The consensus (and accepted answer) is that in general if it's important enough for a local / private inner class to be tested, it should refactored out, e.g. to a separate package.

On the other hand, "bob" makes a good point about keeping the class internal as an implementation detail for the sake of cohesion.

Kai Sternad provides an answer that probably could have been accepted.