Jimmy Bogard - All Comments

re: AutoMapper for Silverlight 3.0 Alpha

Philip Laureano — Sat, 20 Mar 2010 21:59:32 GMT

LinFu.DynamicProxy now has a SL3 port:

http://is.gd/aQGB2

You can change it back from Castle now :)

Automapper y un buen articulo de dise??o de software | Gabriel Rodriguez Plancarte

Sat, 20 Mar 2010 06:36:42 GMT

Pingback from Automapper y un buen articulo de dise??o de software | Gabriel Rodriguez Plancarte

re: No silver domain modeling bullets

Josh Arnold — Thu, 18 Mar 2010 18:43:46 GMT

I think you're spot on here, Jimmy. I was once on the bandwagon of pushing for the code-generation aspect of ORM (both SQL and the domain model in code) but it didn't take long for me to run into too many problems. As you said, it's a great starting point. During my little journey through the world of ORM, I felt like it became pretty clear that it's great at facilitating one thing: communication. Perhaps the best way to describe it is that it helps remove ambiguity and makes it easier to talk about your domain. Rather than spending time clarifying relationships, you have a structured way of discussing the meaning of the relationships.

The title of this post is perfect. My fear would be that anyone that starts using ORM would view it as a silver-bullet. It's simply another tool to help with the process of modeling a domain.

Serializing models for RouteValueDictionary and later model binding

Serializing models for RouteValueDictionary and later model binding — Wed, 17 Mar 2010 20:47:26 GMT

Pingback from Serializing models for RouteValueDictionary and later model binding

re: AutoMapper and IoC

Chester — Tue, 16 Mar 2010 23:04:09 GMT

In the ForMember, I need a service decided on the fly to the lambda expression like this

c => c.MapFrom(s => service(s)).

If using Moq to mock the service, it only works for the first test, the second test will fail. Why?

Maintainable MVC: Binding | blog.jorrit salverda.nl

Maintainable MVC: Binding | blog.jorrit salverda.nl — Tue, 16 Mar 2010 22:19:54 GMT

Pingback from Maintainable MVC: Binding | blog.jorrit salverda.nl

Weekly Links #96 | GrantPalin.com

Weekly Links #96 | GrantPalin.com — Mon, 15 Mar 2010 03:46:00 GMT

Pingback from Weekly Links #96 | GrantPalin.com

A better Model Binder

DotNetKicks.com — Sat, 13 Mar 2010 20:20:19 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: A better Model Binder

kitchaiyong — Sat, 13 Mar 2010 20:19:03 GMT

nice and cool.

Social comments and analytics for this post

uberVU - social comments — Fri, 12 Mar 2010 18:18:30 GMT

This post was mentioned on Twitter by ajepst: Nice practical post on bringing DDD thinking down to the code level, and why you might want to do so http://bit.ly/cKSAWA

Bidirectional Integrity: IEnumerable and read only Entity properties

Sean Blakemore's Blog — Fri, 12 Mar 2010 03:20:06 GMT

Bidirectional Integrity: IEnumerable and read only Entity properties

Sean Blakemore's Blog — Fri, 12 Mar 2010 03:20:03 GMT

Bidirectional Integrity: IEnumerable and read only Entity properties

Sean Blakemore's Blog — Fri, 12 Mar 2010 03:20:00 GMT

Bidirectional Integrity: IEnumerable and read only Entity properties

re: Strengthening your domain: Encapsulated collections

Edin — Thu, 11 Mar 2010 17:16:04 GMT

@Jimmy

I wasn't aware of this approach. Thanks a lot!

re: Strengthening your domain: Encapsulated collections

Markus Zywitza — Thu, 11 Mar 2010 15:30:54 GMT

I'd rather object against the internal AddOrder() method than agaionst IEnumerable. IEnumerable is a clear hands-off sign for modifying.

But rather than have internal AddOrder, I would add

Order CreateOrder() {...}

to Customer. I know that this is slightly less testable, because I cannot stub the Customer for testing, but it is also cleaner. I remember a post from Udi Dahan that emphasizes this method of creating objects in a domain model.