Är det någon mer som bråkar med hibernate i sin domän? räck upp sin hand… de som inte gjorde det var god lämna sidan…

Bra då är det bara vi kvar..

Utan närmare krusidull så vill jag dela med mig av följande problem som uppstod i koden efter ett tag.

Vi har en vy som skall visa upp ett stycke information allt går fint requestet går via sessions bönan ned till slut till domänen som sedemera plockar i hop det data som vyn vill ha .. STOP vänta här han använder inte ett repository nått är tok .. okej en annan implementation vi går till repositoryn och den frågar domänen genom HQL vad vyn vill ha och sedan så får vyn sitt data antigen genom ett frisläppt hibernate proxy aka entiteter eller för hoppningsvis en DTO eller ett Vy objekt, Vy objekt tycker jag beskriver det bättre.

Okej vad är det hemska med detta då kan man fråga? Jo

1. Om DTO/VY lösning med repository där implementation anväder HQL leder i de flesta fall till att man måste mappa upp relationer i domänen som endast är betydelse fulla för dto/vy objekt inte för domänen. aj aj ….

2. Om inte en DTO/Vy utan frisläppta entiteter och open-session-in-view lösning .. en hel massa extra sql slagningar till DB samt en potential “hoppsan jag råka traversera upp min produktion Databas i vyn” … ajajajajaj

3. Samma som ovan fast med restriktionen att entiteter inte är kopplade till en session. Leder detta till en massa LacyInitException i loggen samt arga användare. haha nä.. ajaj

Så vad göra? en lösning på detta om man vill behålla sin rika domän är att endast betrakta sin domän som write-only. Alltså du kan endast skapa,ändra eller tabort data i din domän.

Vill vyn ha data , aggregerat data eller en tårtbit av sin domän-kaka eller blandad data som finns på en helt annan databas så låt den få det men blanda förguds skull inte in domänen i det eller hibernate för den delen. Kör plain SQL eller jdbc template eller dylika.

Detta leder till så mycket mindre huvud bry så du anar inte …

Mer läsning finnes av killen som myntat detta i DDD Greg Young

Rille

Nu är den äntligen här som Rc Ettan för google collections

Här är release notes för 1.0 RC

Laddas ned på denna länk google-collect-1.0-rc1.zip

• com.google.common.annotations package with new annotations for marking types as gwt compatible (GwtCompatible, GwtIncompatible), and marking a type or member as being visible only for testing (VisibleForTesting)
• Joiner, which joins pieces of text together, replacing the old static methods on the Join class.
• Predicate.instanceOf(Class) returns a Predicate that evaluates to true if the object being tested is an instance of the given class.
• MutableClassToInstanceMap and ImmutableClassToInstanceMap, which map a class to an instance of that class.
• ImmutableSetMultimap is a SetMultimap with reliable user specified key and value iteration order.
• Maps.difference(…) computes the difference between two maps, returning the result as a MapDifference.
• Collections2.transform(…) is the Collection-based equivalent of Iterables.transform(..), and returns the Collection that results from applying a Function to each element of a given Collection.
• New ImmutableMultimap.of(..) static methods were added to quickly create immutable maps of specified values.
• ImmutableMultimap.Builder has a new putAll(…) method to store another multimap’s entries in the built multimap.
• Multisets.immutableEntry(E, int) returns a new immutable Multiset.Entry with the specified element and count.
• Multiset has new setCount() methods that can be used to add or remove the necessary number of occurences of an element such that the element attains the desired count.

• http://code.google.com/p/jsr-305/)
• Deprecated Functions.TO_STRING removed in favor of Functions.toStringFunction().
• Functions.toHashCode(). This isn’t a commonly used function, and can be implemented by hand if needed.
• Preconditions.checkContentsNotNull(…)
• Predicates.isSameAs(Object). This wasn’t commonly used, and can be easily implemented by hand.
• The following methods were removed from Iterables: containsNull(Iterable), emptyIterable(), limit(Iterable, int), rotate(List, int), skip(Iterable, int).
• The following methods were removed from Iterators: containsNull(Iterable), emptyListIterator(), limit(Iterator, int), skip(Iterator, int).
• The Multimaps.index(..) method that takes a multimap as the third argument has been removed.
• The Sets.SetView constructor is no longer public (this was an oversight).
• Multiset.removeAllOccurrences(Object). You can replace usages of this with elementSet().remove(Object).
• AbstractMapEntry. Most usages of this can be replaced with java.util.AbstractMap.SimpleEntry/SimpleImmutableEntry provided their keys and values are directly stored in the Entry instance.
• Constraints, Constraint and MapConstraints.
• CustomConcurrentHashMap.
• Serialization.

• ConcurrentHashMultiset.
• Predicates.isEqualTo(T) renamed to Predicates.equalTo(T)
• AbstractIterator now extends UnmodifiableIterator.
• The constructors on ArrayListMultimap, HashBiMap, HashMultimap, HashMultiset, ImmutableBiMap, LinkedHashMultimap, LinkedHashMultiset, LinkedListMultimap, TreeMultimap, and TreeMultiset were removed in favor of new static create() methods which provide type inference. The various static creation methods on Multimaps were removed in favor of create() methods on each Multimap class.
• Iterators.newArray(..) and Iterables.newArray(..) were renamed to toArray(..).
• The instance methods in Ordering are all now final.

Download

En mycket bra presentation av Michael Feathers om hur vi skapar kod som är utan fel.

Bio
Michael Feathers is a consultant with Object Mentor. He balances his time between working with, training and coaching various teams around the world. Publically, Michael developed Cppunit, the initial port of JUnit to C++, and FitCpp, a C++ port of the FIT integrated-test framework. Michael is also the author of the book ‘Working Effectively with Legacy Cod’e ‘ (Prentice Hall 2004).

Presentation

Här är en presentation av Matthieu Ricard. Matthieu är en forskare, fotograf samt buddistmunk som levt i himalay i över 35 år.

Matthieu Ricard ger en ruskigt intressant förläsning om meditation och om hur detta påverkar hjärnan.

Välvärd en timmes sittning.

Inom vårt team fick vi högst prioterat in en bugg som låg mitt i våran domän model, våran prismodell! Detta leder till att en heldrös objekt är inblandade i skapandet av diverse priser. Jag börjde titta på de tester vi har på just på det området inom vår domän och insåg att det var otroligt mycket kod som var duplicerad samt svårtydlig. När sedan bug rättning storyn startade i sprinten tittade jag på olika lösningar inom tdd att arrangera våra fixturer.

Jag såg följande alternativ:

• ObjectMother - en static factory lösning som ger utvecklaren den fixtur som behövs inför sitt enhetstest
• BuilderPattern - en DSL liknande lösning att ge utvecklaren en flexibel fixtur test data lösning baserat på standarn val.

Jag måste ge Nat Pryce super kred! killen är grym! Såg hans exempel på Builder pattern för sina texturer och insåg att detta är det spår vi måste ta.

Efter närmare undersökning så insåg jag att vi redan hadde en hybrid av Object Mother genom en abstract class som inehöll static metoder enligt “create” så som:

createCampaingWithEnclosingBudgetWtihLimitOnClick();

Dessa metoder förökade sig som svampar! genom att varje test i sig är unikt, vilket är bra! Dock leder detta till en Object Mother som är mer som en sur gammal mormor.

Genom att i ställer ta en annan approch genom builder-pattern och att ha smarta default-värden. Plus att ge (enligt tips från Nat pryce) Builders i Builders anrop slippa se en harang av build().build().build(), så får man ett fluent dsl i sin test fixtur. Ruskigt fint för ögat samt att man har den trevliga sideffekten att sina test builders kan leva i test sourcen tills man inser att detta borde ligga i produktions koden direkt!

Ett exempel (Campaign är aggregat objekt):

 Java | 
 copy code |
?
 
1
2
//Given
3
Currency sek = Currency.getInstance("sek");
4
Long id = new Long(1L);
5
Campaign campaign = aCampaign(id).andCurrency(sek).
6
                   withBudget(aLimit(100L).withEvent(aEvent().asClick())
7
                                                       .withPrice(50D).build()
8

En annan sid effekt blir att varje test inte behöver lägga till ett ytterligare createMetod bara pga av ett ytterligare test fixtur. Lägg til buildern med ett smart default värde/builder istället!

Som Josua Bloch propagerar borde varje new vara inkapslat av en builder, så låt nu dina test builders blir riktiga medlemmar av din domän istället!

Finns ruskigt bra argument varför man ska kapsla in new operatorn! men det i en annan post

En kollega till mig (arbetade på samma projekt) har bloggat om ett expriment han har utövat och det är synnerligen intressant! Mycket tänkvärt. Frågan är var går gränsen för hur mycket en PO ska speca? kolla här här

Såg detta från vår käre vän martin fowler och jag tycker det han skriver är synnerligen bra. Jag behövde argument och en påminnelse om detta .

Här är länken AnemicDomainModel

Är det någon mer än jag som hatar dessa ständiga null check kollar i java, i enlighet med Design by contract?!

Och är det någon som har skapat någon “kollaOmNull”-metod som återfinns i någon util klass?

om ja på något av alternativen så kolla in detta i GoggleCollections…

 Java | 
 copy code |
?
 
1
2
public Person(final Long id, final String name, final Integer age) {
3
 
4
Preconditions.checkArgument(id != null);
5
 
6
}
7

Samt om du vill se i en lista eller dylika om det har smygit sig in något null värde.

 Java | 
 copy code |
?
 
1
2
public void setNames(List<String> names){
3
 
4
Preconditions.checkContentsNotNull(names,"A null name was in the Collection!");
5
 
6
this.names = names;
7
 
8
}
9

En myckettrevlig klass för att kolla preconditions finns i flera olika varienter.

Om ni inte vill ta in hela google-collections så ta bara java sourcen och klistra in (copy paste kodning är bra ibland

kommentarer, har ni inte en util-klass liggandes någonstans som gör något liknade?

Hej! satt idag på jobbet och insåg att man skyfflar från ett format till ett annat med alla möjliga snurror. Produkt.getId() till –> List produktIdList;

Såg att Goggle-Collections har en transform metod så det hela resulterade i detta:

 Java | 
 copy code |
?
 
01
02
package functions;
03
 
04
import com.google.common.base.Function;
05
 
06
import domain.Person;
07
 
08
public final class TransformFunctionPersonToId implements Function
09
 
10
{
11
 
12
@Override
13
 
14
public Long apply(final Person personToTransform) {
15
 
16
return personToTransform != null ? personToTransform.getId() : null;
17
 
18
}
19
 
20
}
21

... samt lilla testet..

 Java | 
 copy code |
?
 
01
02
@Test
03
public void testShouldTransformListOfPersonToListOfLong(){
04
 
05
//Given
06
 
07
Person one = new Person(1L,"pär",12);
08
 
09
Person two = new Person(2L,"eno",22);
10
 
11
Person tree = new Person(3L,"leo",32);
12
 
13
Person four = new Person(4L,"pia",42);
14
 
15
List
16
 
17
persons = new ArrayList
18
 
19
();
20
 
21
persons.add(one);
22
 
23
persons.add(two);
24
 
25
persons.add(tree);
26
 
27
persons.add(four);
28
 
29
//When
30
 
31
List<Long> personIdList =
32
 
33
Lists.transform(persons, new TransformFunctionPersonToId());
34
 
35
//Then
36
 
37
Long test = 1L;
38
 
39
for(Long id : personIdList){
40
 
41
System.out.println("ID: "+id);
42
 
43
Assert.assertEquals(id.longValue(),(test++));
44
 
45
}
46
 
47
}
48