D
Подскажите про контракты, что под ними понимают (контракты в программировании)
Size: a a a
2021 May 04
DE
Где так делают?
DP
RL
Здесь - для ленивой инициализации конекшена.
SZ
это вопрос к автору этого кода. и почему один коннект синглтоном делается
SZ
и почему не делали пул коннектов
DP
Есть примеры реализации ?
DE
Описание того, как должен выглядеть и вести себя код. В программировании это обычно делают написанием интерфейса.
DP
Также благодарю за пояснение.
Можно ли сюда добавить, что это сокрытие деталей реализации?
Можно ли сюда добавить, что это сокрытие деталей реализации?
DE
Не особо
SZ
DP
Почему?
DE
Сокрытия деталей больше в классе SqlConnection. А в этой фабрике пока деталей мало.
DE
Фабрика обычно скрывает только детали создания объекта.
DP
+
Очепятался выше)))
Очепятался выше)))
DE
В этом классе фабрикой является только метод CreateNewConnection.
Методы GetOpenConnection и Dispose уже фабрикой не являются.
А метод GetConnectionString вообще лишний, так как приводит к утечке этой детали.
Методы GetOpenConnection и Dispose уже фабрикой не являются.
А метод GetConnectionString вообще лишний, так как приводит к утечке этой детали.
i
Всем привет.
> есть в БД большая сущность с кучей nullable полей, которые заполняются постепенно
> соответственно есть логика с записью и чтением этих полей. Какая-то логика, как правило, не может работать с нулабл полями и такие кейсы надо валидировать
> есть 3 разных клиента, которые работают с этой логикой и везде разные требования, как эту сущность заполнять и читать. Соответственно, разные правила валидации, какие поля должны быть заполнены, а какие нет
Во время эротишных утех с кодом, где надо кучу валидаций на null ptr фигачить у меня возник вопрос - а должна ли возникать такая ситуация? Может есть какие-то подходы, как правильно такое дизайнить?
> есть в БД большая сущность с кучей nullable полей, которые заполняются постепенно
> соответственно есть логика с записью и чтением этих полей. Какая-то логика, как правило, не может работать с нулабл полями и такие кейсы надо валидировать
> есть 3 разных клиента, которые работают с этой логикой и везде разные требования, как эту сущность заполнять и читать. Соответственно, разные правила валидации, какие поля должны быть заполнены, а какие нет
Во время эротишных утех с кодом, где надо кучу валидаций на null ptr фигачить у меня возник вопрос - а должна ли возникать такая ситуация? Может есть какие-то подходы, как правильно такое дизайнить?
AK
по описанию впечатление, что должна быть возможность разделить одну сущность с кучей nullable полей на N сущностей с not nullable полями
AK
как к этому можно придти:
1. сгруппировать поля по тому, когда они заполняются
2. сгруппировать поля по тому, когда они вместе юзаются(например для каждого из клиентов) - я так понимаю это для выгрузки в какие-то системы клиентов
3. сгруппировать поля по тому, когда они вместе влияют на логику, грубо говоря когда они вместе попадают во всякие условия вместе
1. сгруппировать поля по тому, когда они заполняются
2. сгруппировать поля по тому, когда они вместе юзаются(например для каждого из клиентов) - я так понимаю это для выгрузки в какие-то системы клиентов
3. сгруппировать поля по тому, когда они вместе влияют на логику, грубо говоря когда они вместе попадают во всякие условия вместе