@t3chb0t Well that sucks because I took time to write my answer ahah, but I'm almost certain that whatever is added to the code won't make this builder pattern worth it.

Thanks for this. Question... both you and @t3chb0t have referred to me using this pattern to make DTOs... But I don't see it that way, exactly... I'm planning to use this for model objects (primarily), but my pattern is to have the DTOs be a subclass of the model object, with the persistence dependencies. Is this fundamentally flawed? If (and this is not guaranteed of course), my model object's properties closely match what I want in my persistent model, maybe plus some housekeeping properties/methods?

I should add that I'm coming from using EF4 + MVC with pretty much all my business logic in the controllers... and trying to move domain logic into domain model objects and application logic into a service layer. This DTO-as-subclass model made sense to me if I could make it work, and this pattern was one part of getting there. Keeping the setters private is done to help me control state via behavioral model methods, hence I had to think about initializing an object with many properties (domain model or DTO, either way).

@S'pht'Kr yes, it is flawed. Your model class will probably be complex and validation heavy with maybe nested domain classes, where your DTOs should be dummy {get; set;} properties. I don't really have the space to write all the reasons I think it'll probably bounce back in your face, but think of the consequences on contravariance, covariance, on the evolution of your model objects, on the dependencies your DTO will have.

@S'pht'Kr What I mean is, sit down and try to think of all the ways it could go wrong in a month, year, 5 years, if you leave, etc and ask yourself if it's still worth it to go this way

@IEatBagels I get that... absolutely. But I'm not sure I'm convinced subclass-as-DTO is flawed just based on that comment. Maybe I need to make that a separate question over on Software Engineering. Most introductory and intermediate-level stuff using MVC + EF essentially treats the data model as both model object and DTO (with business logic willy-nilly all over the place), this seemed at least somewhat reasonable as a way to make that familiar while breaking the dependency on EF from the domain model layer.

@S'pht'Kr I understand your point, what I'm saying is that the experience I've had with those exact technologies and this exact mindset is that models and DTOs grow apart in the lifetime of the application and that if you couple them you end up with problems.

@IEatBagels Ugh. One more hurdle I'm going to have to get over with the team :-\.

Hey I moved the discussion to chat

'Cause I wanted to write something else and the comments were getting long

Thanks. Yeah, it was getting longwinded.

I just wanted to say that I think you've got a right mindset, it's important to ask yourself if it's a good idea to build tools and try to use them. You'll grow a lot from it. I've grown a lot from trying things that ended up failing, it's probably where I've learnt the most in all my career. Maybe you'll try your thing and it'll work, I just don't think so 'cause it's what I would've tried to do before too.

Yeah I'm doing a lot of that right now. Basically trying to level up 5 years in a few months so I can better lead a group.

I think that experience brings the mindset of "Alright I shouldn't do that because of X consequence", but it takes some tries to get there

Why I threw that solution out there, this was one possible response I was looking for.

So... separate DTOs, and AutoMapper?

What I'd recommend is to get your group involved in the decisions. The more heads are on a problem, the biggest the chance someone will catch a potential problem

Yea.....I want to, and am with some...

But the strongest personality in the group still does all business logic in stored procedures and uses WebForms and is opposed to MVC....

I think that's the best way to go, but I also don't have enough information to give you the answer. Talk with your team, think about it. Making architectural decisions is probably the biggest challenge of software engineering.

So to introduce something approaching DDD is going to require me to have a lot of answers.

Ahah alright, you know what once again that's exactly how it was in my previous team. And the best decisions that were taken were compromises between the DDD expert and the procedural guy.

Try to introduce small things first

Yep. I expect compromise...which is why I'm trying to start as far on one end as i can :-)

That's a good plan, all you gotta do now is keep your ears open to challenges that'll face you (I think you've proven here that you can do this)

You should try to sit in front of the code you've built and try to figure out in which scenarios it could evolve badly or what edge cases you could face, that'd be a good exercise I think

Thanks. Yeah, figuring out what small things to start with is tough. Really want to get logic out of the DB so we can do automated test....but doing that requires many other things to be in place.

Yeah that's for sure, it's a complicated thing to think about

@IEatBagels how can you chat and post answers at the same time :-O are you cloned? :P

@t3chb0t Maybe.. :p

I started writing my answer to the other post before going into chat ahah

oh, cheating so it looks like you were writing in parallel... nice, and without deadlocks ;-]

@S'pht'Kr you might find this interesting: codereview.stackexchange.com/questions/226694/… -- fresh, just asked

@t3chb0t I feel obligated, considering the subject at hand, to ask : Why would you use this instead of using the ctor? Ahah

@IEatBagels this one is tough ;-P let me think....

ok, I have no idea ;-[

Ahaha alright then, as I said it's great to experiment