Krzysztof Kozmic - All Comments

re: Advanced Castle Windsor – generic typed factories, auto-release and more

OutOFTouch — Thu, 29 Nov 2012 14:58:37 GMT

I am confused a little by this statement

"It does not even know what actual type of command it got."

Didn't the code explicitly create a specific command of type UpdateClientCorrespondenceAddressCommand?

re: On testing

David Hogue — Wed, 28 Nov 2012 17:43:12 GMT

@Wayne: I have had to push to get several tools like NUnit, NHibernate, MVC, etc adopted. It wasn't always an easy process and things didn't always turn out like I wanted. One downside of that, at least in my head, is because I did push for these things I feel a little bit responsible when the code ends up really ugly or the concepts are harder to teach than I would have thought. I still think it's been worth it though, the code is more reliable and maintainable than in the old days.

Unfortunately because these tools and techniques are something to build apps on top of, they aren't that visible and there probably won't be a push from the higher ups in the company for them. The thing that works best is if you can show how you were able to get things done faster or better than without them.

As far as going back to the basics, I think it could be helpful. I sometimes search for posts like that to forward on, and if the post is from 2002 when NUnit 2.0 came out I'll be less likely to pass it on.

re: On testing

Wayne Molina — Tue, 27 Nov 2012 16:52:16 GMT

+1 Nick; too many posts say how great design patterns or testing or whatever (IoC, ORM, your choice of acronym) but show some trivial application that doesn't help when you are in the real world.

Yes, I understand the benefit of unit testing. I've never worked at any place that saw a need for it, saw a benefit to devoting time to writing tests (to say nothing of TDD), or had a codebase that could support unit testing without spending months refactoring or even rewriting parts of it to be able to write a test. That's where I get stumped - as nice as tests are you can't justify it when the team has to spend a month refactoring (and, therefore, not providing tangible value) just to be able to write tests around the code.

For all the blogs that I read, all the best practices that I try to adhere to, the reality has always been that this stuff is the domain of the innovators and early adopters; I think in several years as a .NET developer I've met maybe one or two people that even knew these blogs exist, or even bothered to look at open source for beneficial tools, and when I would mention these things I'd be looked at like I was insane.

I really envy you people that get to work with things like MVC, NHibernate, Windsor/Structuremap/Ninject, and the like, because you don't have to fight uphill battles with people that have never even HEARD of NHibernate or NUnit or MVC, and have no desire to learn. You don't have to risk getting fired for trying to push software craftsmanship and quality.

re: On testing

Nick — Tue, 27 Nov 2012 14:24:49 GMT

There are a ton of posts on how to do silly simple unit tests. How about how to make something testable? Like legacy code, or even the patterns needed to make code testable. No simple calculators but some real business problem. That is what I find hard. If I were writing some calculator I'd know what to do, applying that knowledge to real business code is where I fail.

re: On testing

Adriaan — Tue, 27 Nov 2012 10:25:20 GMT

Good idea. Looking forward to the series.

re: On testing

Rémi BOURGAREL — Tue, 27 Nov 2012 08:27:18 GMT

I absolutly agree with you, most of the blog posts I read are about the basic. I loved the last series from ayende about the design patterns like I love Jim Bogard's posts about testing.

Looking for your next posts !

re: How to force Nuget not to update log4net to 1.2.11

Neeraj — Thu, 01 Nov 2012 21:42:45 GMT

Hi Dominick,First of all, I want to say i've been a big fan of your work, especially WIF topcis. Reading your blog is the first thing i've been doing every moring the past 2 months. With the release of this Thinktecture.IdentityModel.40, i'm wondering if there is any plan to update the IdentityServer (.Net 4 version) to make use of this library and also offer support JWT from the OAuth2 endpoint? I've started to do the conversion and making to changes to the IdentityServer source code but i'm not 100% confident on whether i've done it correctly.Thanks,Ryan N

re: IoC container solves a problem you might not have but it's a nice problem to have

Dmitriy Startsev — Sun, 28 Oct 2012 22:14:06 GMT

Guilherme, can you explain how large number of abstractions breaks maintainability of application?

Maybe a physical structure of project (files, directories) makes harder to navigate through large number of files? Then you should reorganize it.

Maybe dependency graph is too complex to understand? Then you should visualize it.

Maybe there is any other problem, which I don't see?

re: IoC container solves a problem you might not have but it's a nice problem to have

Guilherme — Thu, 25 Oct 2012 13:35:40 GMT

You should read Ayende's series on limiting your abstractions, its really great. In my projects, one of the first things I would do is get my favorite container up and running and start creating IServices, IRepositories etc. Soon enough, my project would get full of interfaces and dependencies everywhere to the point where it was no longer workable. Since I realized that started to take a more pragmatic approach and NOT using a container unless it's strictly necessary. ayende.com/.../limit-your-abstractions-analyzing-a-ddd-application

re: To constructor or to property dependency?

Neil Kidd — Tue, 23 Oct 2012 22:49:30 GMT

I'm with Dathan on this. After construction any object should be "good to go" and immutable. Optional parameters can be taken care of in a constructor overload that chains, with safe defaults (think null object pattern), to one single constructor. Properties are evil! except in DTO's. If you require different parameters, maybe you are missing an object?

Regards,

Neil

re: To constructor or to property dependency?

Eber Irigoyen — Tue, 02 Oct 2012 15:46:23 GMT

I don't necessarily agree with your approach, I'm just curious how this is working for you, especially if you have quite a few other developers on your team

re: To constructor or to property dependency?

Dathan — Thu, 27 Sep 2012 17:58:36 GMT

We have a simple rule: whenever possible, objects should be fully initialized and ready to use as soon as the constructor returns -- implying, of course, that all required dependencies are injected via the constructor. It does sometimes cause problems (e.g., complicating constructors in derived classes), but if you're in the happy position of being able to depend on interfaces instead of classes, most of those problems are easily mitigated through composition instead of inheritance.

re: To constructor or to property dependency?

Chris Brandsma — Thu, 27 Sep 2012 00:35:46 GMT

It is also important to remember the anti-pattern of DI: Too many constructor parameters!

Now, I like IoCs and DP. But there is an issue that can happen with large projects over time where DI is too freely used, you end up with classes where there are a TON of constructor parameters, and each parameter can have a ton of its own parameters. Suddenly you find you are injecting 100s of classes to create a web page.

DI makes it very easy to loose track of what is going on and inject subtle problems when overused.

Then throw on auto scanning, and now your project takes extra seconds (lots of them) to load.

re: Castle Windsor new feature – dynamic parameters from registration site

Hills — Wed, 26 Sep 2012 11:50:29 GMT

Cool, but DateTime is no primitive. msdn.microsoft.com/.../ms228360%28v=VS.80%29.aspx

re: To constructor or to property dependency?

Ramon Smits — Tue, 18 Sep 2012 19:54:42 GMT

I like constructor dependency injection as it helps to change code fast without missing any clients. Using property injection can result in having clients that 'forget' to inject a value resulting in broken unit tests. I rather have compile time issues then at runtime.

However, I think that the data session is infrastructural as wel. It is generic, it has transactions that are managed somewhere else. Having something to send messages to is IMHO the same thing.