|
I would go for option 1.
I would also look at having some sort of mapping functionality so that the values can be populated 'automatically' by passing the DTO to some form of orchestrator together with the data source to populate it.
The following in option 2 is a huge code smell:
public FooDto(T1 value1 , T24 value24)
I have done this myself in the past but it is generally accepted nowadays that a large number of parameters in a signature is a bad idea.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 30-Oct-18 4:35am.
|
|
|
|
|
I fail to see what the big deal is about, but if I get to choose I prefer 1.
I don't like huge constructors, they are slightly more error prone.
|
|
|
|
|
Option 1 because it is cleaner, more understandable and more extensible of the two options.
|
|
|
|
|
Option 1.
Agree that Too much parameters in Option 2 is terrible one. Too much parameters require changes in other places(Ex: Business Logic layer, Code-behind, etc.,) when you need to remove/add parameters later.
|
|
|
|
|
Really blow his mind. Make the constructor accept a Tuple instead.
This space for rent
|
|
|
|
|
that's a good one!
in fact it might the easiest way how to go about it.. by that I mean I can implement that with some quick copy paste...
whereas implementing the constructor is going to be manually intensive and bug prone!
|
|
|
|
|
Super Lloyd wrote: In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values.
Yeah, initialization does not inherently mean useful values, so why force lazy coders to initialize meaningless values?
var dto = new FooDto(actualT1Val,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null);
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
|
I think I might add a couple of unit test just like that, for giggle...
|
|
|
|
|
I don't mind either option, but I think I like v1 better.
When it comes to long lists of assignments I generally copy/paste back and forth with an instance of Excel.
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
Super Lloyd wrote: select your favourite of 2 options. I prefer favorite.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
I live in Australia..... I am giving in the local area grammar Nazi...
|
|
|
|
|
Down-vote!
Outside of a dog, a book is a man's best friend; inside of a dog, it's too dark to read. -- Groucho Marx
|
|
|
|
|
Neither. One does not "force" all or none.
The constructor-parameters are added for all variables that the object needs before it can initialize. Any other option that can be set later should be a public property. If you have more than three parameters, consider creating a class for them and to pass the thing to the constructor.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
it's a DTO, i.e. all those could be field really (except it would sparkle another argument). No code is either run into that class, just a bag of well known property....
|
|
|
|
|
The same still applies; anything that is required should be there in the constructor. If it is not required for the objects existence, then it becomes a property. For a DTO, I'd expect an Id-field, and without an Id such object should not exist.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Neither. It shouldn't be the responsiblity of MyFooClass to return a FooDto, it should be FooDto's class to take a MyFooClass and convert it to a FooDto.
So you have instead:
public class FooDto
{
public static FooDto From(MyFooClass c)
{
}
}
And to make this more re-usable for different data objects and to avoid repeating From for every type of "from - to" conversion, use interfaces:
public class FooDto : IFooDto
{
public static IFooDto From(IFooClass c)
{
}
}
This promotes consistency between properties in FooDto and properties in the "from" class that can be mapped to FooDto .
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Of the two choices given, I'd take 1; but would prefer a third option.:
public class FooDto
{
public FooDto(MyFooClass foo)
{
Property1 = foo.property1;
Property24 = foo.property24;
}
public T1 Property1 { get; }
public T24 Property24 { get; }
}
class MyFooClass
{
private T1 property1;
private T24 property24;
}
If for some reason I
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
If you really want to bake their noodle, put all the value maps in Attributes and then have the object built via Reflection such as in this article[^]. It's a super complicated way to do simple tasks
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
public class Foo
{
public class DTO
{
public T1 P1 { set; get; } = P1_default_value;
...
public T24 P24 { set; get; } = P24_default_value;
}
public void In(DTO dto)
{
}
public DTO Out()
{
DTO dto = new DTO();
return dto;
}
private T1 _P1;
...
private T24 _P24;
} The DTO object constructs itself with a consistent default set of values. The DTO property accessors are responsible for maintaining consistency of that set. The In and Out methods of the Foo class manage its internal state based on accepting or producing a DTO, respectively. This approach lets you do things like this:
Foo foo = new Foo();
...
foo.In(new DTO() { P3 = Fred, P17 = Wilma; });
Foo foo2 = new Foo();
foo2.In(foo.Out());
Software Zen: delete this;
|
|
|
|
|
So option 1 gives you simplicity, whereas option 2 gives you immutability. There are arguments for both, the immutability one being that one DTO can be safely shared by many things as none of them can alter it. With option 1, by rights you need to keep cloning the thing to prevent any badly behaved code messing up the 'master' copy. So there's a memory/performance trade off with all that. You often get that cloning for free through serialization mind.
That said, when you wish to change one property on option 2, it becomes a screaming nightmare of reconstructing a new one with one difference in the constructor parameter list. We had option 2, but it was too much to stomach in the end.
Regards,
Rob Philpott.
|
|
|
|
|
|
It depends.
I use option 2 only for values that are absolutely necessary for the class to work (and that should never be 24 parameters, that's just bad design!).
And option 2 is ideal for constructor injection in DI.
Other than that, option 1.
|
|
|
|
|
Could you not just use inheritance and do away with all the property setting?
public class FooDto
{
public FooDto(T1 value1 , T24 value24)
{
Property1 = value1;
Property24 = value24;
}
public T1 Property1 { get; }
public T24 Property24 { get; }
}
class MyFooClass : FooDto
{
}
This exposes properties T1 ... T24 of the base FooDto class but that may or may not be an issue. There are arguments against combining DTOs and inheritance, so without knowing the details of your implementation this may not be appropriate. Part of "knowing the details" of course involves the use of a crystal ball to envisage future changes, but depending on the scenario you can pretty much rule out a lot of potential stuff and, in this case, save yourself a lot of code.
|
|
|
|
|
Such a FoodDto is absolutely useless, a snapshot in time...
There is little point in deriving from it...
This FooDto sole purpose is to be turned into json and vice versa. It comes from an object that do update each individual property in real time (mostly hardware read status)
|
|
|
|