Dealing with the "Too many dependencies" problem

http://hadihariri.com/2012/04/09/dealing-wht-the-too-many-dependencies-problem/
http://blog.ploeh.dk/2010/01/20/RebuttalConstructorover-injectionanti-pattern/
http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/
http://stackoverflow.com/questions/427659/going-bananas-with-loose-coupling-and-dependency-injection
http://programmers.stackexchange.com/questions/163335/dependency-injection-ioc-container-practices-when-writing-frameworks

Reference Counting in C#

Some ancient article about problems with reference counting.

http://blogs.msdn.com/b/brada/archive/2005/02/11/371015.aspx

And much shorter version of it :)
http://stackoverflow.com/questions/867114/why-no-reference-counting-garbage-collection-in-c/908981#908981

Why DRY?

http://blog.ploeh.dk/2014/08/07/why-dry/

Luźne rozważania na temat N-tier

Ostatnio miałem pewne problem z architekturą w projekcie i podziałem klas między projektami.
Zauważyłem, że jest to bardzo subiektywny temat dla różnych programistów.
Chciałbym uchwycić skąd pochodzi to subiektywne podejście. Takie "brain dump", może bez sensu.

--

Wszystkie obiekty są równe. Jedne rodzą się biedne a drugie bogate, jedne są mądre a drugie nie. :)
Każdy ma swoją matkę "fabrykę", Ona je rodzi.
Dla obiektu nie ma znaczenia w jakim miejscu istnieje jego rodzic (np. IoC, fabryka, builder, singleton).

Kod genetyczny każdego obiektu (np. IL) musi być gdzieś umieszczony. 
U ludzi kod jest w rodzicach. Ale rzeczy na świecie powstają z innych źródeł.
Obraz na telewizorze ma swój kod z satelity w kosmosie. Chleb z wiedzy piekarza. UIElement z XAMLa.
To gdzie kod genetyczny obiektu jest umieszczony nie zmienia jego celu, wyglądu ani zachowania.
Być może dlatego nie ma znaczenia gdzie kod klasy będzie umieszczony.

Jedyne co różni obiekty to cel w jakim mogą zostać użyte. 
Celów są tysiące. Według SOLID każdy obiekt ma wyłącznie jeden cel (S -> responsibility).

Obiekty czasem używamy wspólnie, aby tworzyć kompozyty.
Nie chce nam się za każdym razem wybierać ręcznie zestawu zależności (np. klas składowych). 
Dlatego referencjonujemy całą bibliotekę, więcej niż potrzebujemy.
Może tu jest cały problem. Ale to rozważania na inny moment.

Żeby sobie ułatwić życie ludzie zaczęli grupować obiekty w biblioteki. I tu jest kłopot :)
Każdy zestaw obiektów można pogrupować na kombinatoryczna ilość grup.
Po jednej stronie ekstremum mamy jedną grupę/bibliotekę z wszystkimi typami, po drugiej stronie grupy z wyłącznie jednym elementem.

Z drugiej strony chcemy sobie grupowaniem sprawę utrudnić. Np. wprowadzając w zespole zasady jakie biblioteki wolno wciągać a jakie nie.

OK. Zatem o co chodzi z tym N-Tier? Dlaczego BLL, DAL, warstwa prezentacji? Skąd ten podział, czy ma sens?

WPF: Specify your DataContext type

http://n3tm4n.wordpress.com/2012/02/20/wpf-specify-your-datacontext-type/

<StackPanel d:DataContext="{d:DesignInstance vm:BookViewModel}">
    <TextBlock Text="{Binding Path=Author, Mode=OneWay}" />
    <TextBlock Text="{Binding Path=Title, Mode=OneWay}" />
</StackPanel>


http://blog.galasoft.ch/posts/2014/04/xaml-intellisense-just-got-better/
http://msdn.microsoft.com/en-us/library/ff602274(v=vs.95).aspx

Why I use explicit interface implementation as a default implementation technique

Taki smaczek :)
http://www.codeproject.com/Articles/392516/Why-I-use-explicit-interface-implementation-as-a-d

A co tam pochwalę się :P



Właśnie udało mi się zdać Profesional Scrum Master I (za drugą próbą). Przy pierwszej 84% a teraz 97.5.. ta daaaa... :)

Randka z Nancy

http://nancyfx.org/

Z wczorajszego http://www.meetup.com/wrocnet/events/164088072/ spotkania Wrocławskiej Grupy .NET.
Bardzo dobra prezentacja http://www.maciejaniserowicz.com/.

Warto też rzucić okiem na TinyIoC.
https://github.com/grumpydev/TinyIoC

ORM anti-patterns - Part 3: Lazy loading

http://www.mehdi-khalili.com/orm-anti-patterns-part-3-lazy-loading

Troszkę o N-tier

http://msdn.microsoft.com/en-us/magazine/dd882522.aspx
http://www.codeproject.com/Articles/493389/Four-ways-of-passing-data-between-layers
http://stackoverflow.com/questions/837697/where-should-datasets-reside-in-a-n-tier-multi-layered-architecture?rq=1
http://stackoverflow.com/questions/533311/how-strictly-do-you-follow-the-n-tier-architecture-and-separation-of-concerns-be?rq=1
http://stackoverflow.com/questions/312187/what-is-n-tier-architecture?rq=1
http://imar.spaanjaars.com/573/aspnet-n-layered-applications-introduction-part-1
http://msdn.microsoft.com/en-us/magazine/dd882522.aspx
http://www.drdobbs.com/errant-architectures/184414966

Disassembler C++ online

http://gcc.godbolt.org/

Unity container

Unity Developer's Guide covers various styles of dependency injection and also additional capabilities of Unity container, such as object lifetime management, interception, and registration by convention. It also discusses the advanced topics of enhancing Unity with your custom extensions.

http://unity.codeplex.com/documentation
http://www.palmmedia.de/Blog/2011/8/30/ioc-container-benchmark-performance-comparison

Guide: Writing Testable Code

Bardzo dobry artykuł.
http://misko.hevery.com/code-reviewers-guide/

Loading of 32-bit dll to AnyCPU .NET process

Some useful links.

C:\Program Files\Microsoft.NET\SDK\v2.0\Bin\CorFlags.exe
http://www.codeproject.com/Articles/383138/BadImageFormatException-x86-i-x64

ComVisible
http://stackoverflow.com/questions/3036971/32-bit-dll-importing-in-64-bit-net-application

AnyCpu mode does not exist for C++/CLI
http://www.codeproject.com/Articles/442784/Best-gotchas-of-Cplusplus-CLI
http://stackoverflow.com/questions/7727876/any-cpu-dependent-on-c-cli-dependent-on-native-c-dll-any-cpu-for-c-cli

Automatically Choose 32 or 64 Bit Mixed Mode DLL’s (don't :) use paths instead of)
http://scottbilas.com/blog/automatically-choose-32-or-64-bit-mixed-mode-dlls
http://scottbilas.com/blog/automatically-choose-32-or-64-bit-mixed-mode-dlls/#comment-657



Coupling and cohesion

http://c2.com/cgi/wiki?CouplingAndCohesion

 
Tomasz Kulig