Сообщение Re[39]: Что если не разделять строго dto, entity, bo... от 01.02.2026 2:25
Изменено 01.02.2026 4:49 Sinclair
Re[39]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Речь про долгосрок, про подстелить себе салому, а не дурака валять с ООП. Все-таки на долгий срок
S>если выбирать, то питон решение выглядит солиднее, чем sql скрипт + обвязка на C#. Во втором случае скорее
S>всего во что-то упретесь и придется переписывать с нуля, а в первом добавить немного кода.
Скорее всего наоборот: в питоновом решении упрётость наступит примерно сразу, и придётся переписывать всё это нагромождение паттернов друг на друга.
А в С# кода мало, даже если его придётся целиком переписать — не жалко. Да и переписывать-то скорее всего не придётся — учёт статусов и чего угодно делается добавлением предикатов к запросу.
Как только предикаты становятся сложными и начинают использоваться в нескольких местах — код уезжает из каждого конкретного запроса в функцию, которой пользуются все:
S>Также напомню читателям, что моделировать модель предметную область гораздо лучше, чем обновлять соотв. строки в бд.
Вопрос не в том, моделировать ли. Вопрос — в том, как моделировать.
Тот самый Липперт же не предлагает отказаться от программирования D&D. Он предлагает другую модель, которая, в отличие от наивного подхода с new Warrior(), работает.
S>Да, дольше и сложнее, но на долгосрок самое то.
Нет.
S>Речь про долгосрок, про подстелить себе салому, а не дурака валять с ООП. Все-таки на долгий срок
S>если выбирать, то питон решение выглядит солиднее, чем sql скрипт + обвязка на C#. Во втором случае скорее
S>всего во что-то упретесь и придется переписывать с нуля, а в первом добавить немного кода.
Скорее всего наоборот: в питоновом решении упрётость наступит примерно сразу, и придётся переписывать всё это нагромождение паттернов друг на друга.
А в С# кода мало, даже если его придётся целиком переписать — не жалко. Да и переписывать-то скорее всего не придётся — учёт статусов и чего угодно делается добавлением предикатов к запросу.
Как только предикаты становятся сложными и начинают использоваться в нескольких местах — код уезжает из каждого конкретного запроса в функцию, которой пользуются все:
var db = ctx.Database;
await db.CreateExecutionStrategy().ExecuteAsync(async ct =>
{
await using var t = await db.BeginTransactionAsync(System.Data.IsolationLevel.Serializable, ct);
await ctx.Issues.Where(i => i.Id == id).ExecuteUpdateAsync(s => s.SetProperty(x => x.UserId, userId), ct);
if (await ctx.СountUserIssues(userId, ct) > ctx.GetMaxUserIssues(userId)) throw new Exception("Auchtung");
}, ct);S>Также напомню читателям, что моделировать модель предметную область гораздо лучше, чем обновлять соотв. строки в бд.
Вопрос не в том, моделировать ли. Вопрос — в том, как моделировать.
Тот самый Липперт же не предлагает отказаться от программирования D&D. Он предлагает другую модель, которая, в отличие от наивного подхода с new Warrior(), работает.
S>Да, дольше и сложнее, но на долгосрок самое то.
Нет.
Re[39]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Речь про долгосрок, про подстелить себе салому, а не дурака валять с ООП. Все-таки на долгий срок
S>если выбирать, то питон решение выглядит солиднее, чем sql скрипт + обвязка на C#. Во втором случае скорее
S>всего во что-то упретесь и придется переписывать с нуля, а в первом добавить немного кода.
Скорее всего наоборот: в питоновом решении упрётость наступит примерно сразу, и придётся переписывать всё это нагромождение паттернов друг на друга.
А в С# кода мало, даже если его придётся целиком переписать — не жалко. Да и переписывать-то скорее всего не придётся — учёт статусов и чего угодно делается добавлением предикатов к запросу.
Как только предикаты становятся сложными и начинают использоваться в нескольких местах — код уезжает из каждого конкретного запроса в функцию, которой пользуются все:
S>Также напомню читателям, что моделировать модель предметную область гораздо лучше, чем обновлять соотв. строки в бд.
Вопрос не в том, моделировать ли. Вопрос — в том, как моделировать.
Тот самый Липперт же не предлагает отказаться от программирования D&D. Он предлагает другую модель, которая, в отличие от наивного подхода с new Warrior(), работает.
S>Да, дольше и сложнее, но на долгосрок самое то.
Нет.
S>Речь про долгосрок, про подстелить себе салому, а не дурака валять с ООП. Все-таки на долгий срок
S>если выбирать, то питон решение выглядит солиднее, чем sql скрипт + обвязка на C#. Во втором случае скорее
S>всего во что-то упретесь и придется переписывать с нуля, а в первом добавить немного кода.
Скорее всего наоборот: в питоновом решении упрётость наступит примерно сразу, и придётся переписывать всё это нагромождение паттернов друг на друга.
А в С# кода мало, даже если его придётся целиком переписать — не жалко. Да и переписывать-то скорее всего не придётся — учёт статусов и чего угодно делается добавлением предикатов к запросу.
Как только предикаты становятся сложными и начинают использоваться в нескольких местах — код уезжает из каждого конкретного запроса в функцию, которой пользуются все:
var db = ctx.Database;
await db.CreateExecutionStrategy().ExecuteAsync(async ct =>
{
await using var t = await db.BeginTransactionAsync(System.Data.IsolationLevel.Serializable, ct);
await ctx.Issues.Where(i => i.Id == id).ExecuteUpdateAsync(s => s.SetProperty(x => x.UserId, userId), ct);
if (await ctx.СountUserIssues(userId, ct) > await ctx.GetMaxUserIssues(userId)) throw new Exception("Auchtung");
}, ct);S>Также напомню читателям, что моделировать модель предметную область гораздо лучше, чем обновлять соотв. строки в бд.
Вопрос не в том, моделировать ли. Вопрос — в том, как моделировать.
Тот самый Липперт же не предлагает отказаться от программирования D&D. Он предлагает другую модель, которая, в отличие от наивного подхода с new Warrior(), работает.
S>Да, дольше и сложнее, но на долгосрок самое то.
Нет.