Здравствуйте, vaa, Вы писали:
vaa>По ситуации. vaa>Начнем с того, а точно нужен класс с 40 полями? vaa>Ну и сразу же становится ясна культура сишарп разработчика.
При чем тут культура, если список полей определяется требованиями?
vaa>вместо того чтобы написать корректный конструктор,
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vaa, Вы писали:
vaa>>По ситуации. vaa>>Начнем с того, а точно нужен класс с 40 полями? vaa>>Ну и сразу же становится ясна культура сишарп разработчика.
НС>При чем тут культура, если список полей определяется требованиями?
Я имел ввиду не количество полей.
Культура в том, что инициализатор объекта позволяет задавать любые значения, в том числе некорректные,
Хотя в справочнике Албахари написано, что он используется для упрощения создания объекта. И в чем же оно?
Объективно, эта техника разумна только в случае создания анонимных типов.
Именованные классы как правило используются в нескольких методах,
и тогда нормальный конструктор позволяет избавиться от дублирования кода.
vaa>>вместо того чтобы написать корректный конструктор,
НС>Покажи корректный ктор на 40 полей.
Здравствуйте, vaa, Вы писали:
vaa>Культура в том, что инициализатор объекта позволяет задавать любые значения, в том числе некорректные,
Некорректность — понятие относительное. Логику проверки корректности засовывать в DTO, к примеру — скорее всего плохая идея.
НС>>Покажи корректный ктор на 40 полей. vaa>Не я придумал это сакральное число
Но ты заявил, что все ОК если конструктор корректный.
public class PersonA
{
public string Name { get; set; }
public int Age { get; set; }
}
public class PersonB
{
public string Name { get; set; }
public int Age { get; set; }
}
internal class Program
{
#region Methods
private static void Main(string[] args)
{
var list = new List<PersonA>(16);
for (int i = 0; i < 10; i++)
{
list.Add(new PersonA(){Age = i,Name = i.ToString()});
}
IEnumerable<PersonB> q = list.Select(p =>
{
var temp = new PersonB();
temp.Age = p.Age;
temp.Name = p.Name;
return temp;
});
}
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Что не так? Все компилируется. НС>Название переменной db тебя не на какие мысли не навело? Например на то что там не IEnumerable, а IQueryable?
И что IQueryable? Ну выполнится запрос на стороне бд и вернется результат и далее преобразуем в Person, почему не будет работать?
Здравствуйте, Sharov, Вы писали:
НС>>Название переменной db тебя не на какие мысли не навело? Например на то что там не IEnumerable, а IQueryable? S>И что IQueryable? Ну выполнится запрос на стороне бд и вернется результат и далее преобразуем в Person, почему не будет работать?
Здравствуйте, Sharov, Вы писали:
S>>>Что не так? Все компилируется. НС>>Название переменной db тебя не на какие мысли не навело? Например на то что там не IEnumerable, а IQueryable? S>И что IQueryable? Ну выполнится запрос на стороне бд и вернется результат и далее преобразуем в Person, почему не будет работать?
Нет, это ломает всю идею IQueryable. Оно должно быть expression tree — это дает возможность (хотя бы теоретическую) преобразовать запрос во что-то, исполняемое на сервере.
.Select( x => new Dto{ x.Age } )
так можно, потому что есть дерево выражений и можно написать преобразователь его в, например, SQL. Или еще какой там серверный язык запросов.
а если
.Select( x => { return new Dto{ x.Age }; } )
то что там происходит в лямбде — темный лес и преобразовать его ни во что нельзя, только создание на клиенте. Но тогда это уже не IQueryable по сути своей.
Потому такой синтаксис доступен только для IEnumerable.
Попробуй у себя сделать list.AsQueryable().Select( ... ) и увидишь что больше не компилируется.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>И что IQueryable? Ну выполнится запрос на стороне бд и вернется результат и далее преобразуем в Person, почему не будет работать? НС>Потому что не скомпилируется.
Ага, благодарю, понял. Круто, т.е. это спец. синтаксический сахар для деревьев выражений, т.е. чтобы провайдер мог сгенерировать соотв. код.
С др. стороны -- https://www.geeksforgeeks.org/object-and-collection-initializer-in-c-sharp/ (то, как я это описал).
Т.е. в случае IQueryable компилятор вообще что ли код не будет генерировать, а это будет делать соотв. провайдер (транслятор из C# в sql, например)?
Здравствуйте, Sharov, Вы писали:
S>Т.е. в случае IQueryable компилятор вообще что ли код не будет генерировать, а это будет делать соотв. провайдер (транслятор из C# в sql, например)?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vaa, Вы писали:
vaa>>Культура в том, что инициализатор объекта позволяет задавать любые значения, в том числе некорректные,
НС>Некорректность — понятие относительное. Логику проверки корректности засовывать в DTO, к примеру — скорее всего плохая идея.
внутри метода, анонимные типы для выборки из orm возможно, хотя и тут вопрос,
если у вас есть сущность person типа Person, возникает вопрос зачем вам его преобразовывать еще в какое-то DTO или анонимный тип.
Тогда это не сущность никакая, а банальный Typed DataSet.
НС>>>Покажи корректный ктор на 40 полей. vaa>>Не я придумал это сакральное число
НС>Но ты заявил, что все ОК если конструктор корректный.
Встречный вопрос: что плохого в конструкторе с 40-50-60 полями в сравнении с инициализатором объекта, кроме случая анонимного типа?
Здравствуйте, vaa, Вы писали:
vaa>если у вас есть сущность person типа Person, возникает вопрос зачем вам его преобразовывать еще в какое-то DTO или анонимный тип.
Непонятен вопрос. Если ты нагородил rich domain model, то ты ССЗБ, вне зависимости от наличия или отсутствия конструктора. А вот если нет, то никакой отдельной специальной сущности у нас нет.
НС>>Но ты заявил, что все ОК если конструктор корректный. vaa>Встречный вопрос: что плохого в конструкторе с 40-50-60 полями в сравнении с инициализатором объекта, кроме случая анонимного типа?
Например то, что в каждой конкретной ситцуации может понадобится сильно меньше полей.
Здравствуйте, vaa, Вы писали:
vaa>На днях осознал, что инициализация при создании объекта vaa>
vaa>var person = new Person
vaa>{
vaa> Name = "Alice",
vaa> Age = 12
vaa>};
vaa>
vaa>ничем не лучше старого способа: vaa>
vaa>var person = new Person();
vaa> person.Name = "Alice";
vaa> person.Age = 12;
vaa>
vaa>код даже короче. vaa>Может пора провести ревизию и выкинуть ненужное из шарпов?
На самом деле в первом варианте еще и подсказочки есть на не добавленные свойства.
Ну и не вижу чем короче? person то добавлять надо. Мне эта фича нравится и использую особенно когда свойств значительно больше чем 2
и солнце б утром не вставало, когда бы не было меня
S> На самом деле в первом варианте еще и подсказочки есть на не добавленные свойства. S>Ну и не вижу чем короче? person то добавлять надо. Мне эта фича нравится и использую особенно когда свойств значительно больше чем 2
в том то и дело что только подсказки.
А должна быть гарантия:
var person = new Person("Alice");
public class Person
{
public string Name {get; set;}
public int Age {get; set;}
public Person(string name, int age = 0)
{
Name = string.IsNullOrEmpty(name) ? throw new Exception() : name;
Age = age < 0 ? throw new Exception() : age;
}
}
Считаю инициализация объекта оправдана только при создании экземпляров анонимных типов.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Serginio1, Вы писали:
S>> На самом деле в первом варианте еще и подсказочки есть на не добавленные свойства. S>>Ну и не вижу чем короче? person то добавлять надо. Мне эта фича нравится и использую особенно когда свойств значительно больше чем 2 vaa>в том то и дело что только подсказки. vaa>А должна быть гарантия: vaa>
vaa>var person = new Person("Alice");
vaa>public class Person
vaa>{
vaa> public string Name {get; set;}
vaa> public int Age {get; set;}
vaa> public Person(string name, int age = 0)
vaa> {
vaa> Name = string.IsNullOrEmpty(name) ? throw new Exception() : name;
vaa> Age = age < 0 ? throw new Exception() : age;
vaa> }
vaa>}
vaa>
vaa>Считаю инициализация объекта оправдана только при создании экземпляров анонимных типов.
А зачем гарантия? Зачем заполнять дефолтные значения заного?
и солнце б утром не вставало, когда бы не было меня
vaa>>Считаю инициализация объекта оправдана только при создании экземпляров анонимных типов. S> А зачем гарантия? Зачем заполнять дефолтные значения заного?
Логика программы на что-то должна опираться?
Чем городить проверки на каждом этапе, лучше разрешить только валидные значения на входе.
Здравствуйте, vaa, Вы писали: S>> А зачем гарантия? Зачем заполнять дефолтные значения заного?
vaa>Логика программы на что-то должна опираться? vaa>Чем городить проверки на каждом этапе, лучше разрешить только валидные значения на входе.
Так дефолтные вполне себе валидные. Нужно дать только те которые отличаются от дефолтных.
Так и в разного рода оборудовании итд где огромное количество параметров.
и солнце б утром не вставало, когда бы не было меня
