1. C# / Говнокод #24942

    +1

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    public class TransactionRequestViewModel
    {
            public string X_login { get; set; }
    
            public double X_amount { get; set; }
    
            public int X_fp_sequence { get; set; }
    
            public int X_fp_timestamp { get; set; }
    
            public string X_fp_hash { get; set; }
    
            public string X_show_form { get; set; }
    
            public string X_receipt_link_method { get; set; }
    
            public string X_receipt_link_text { get; set; }
    
            public string X_receipt_link_url { get; set; }
    
            public string X_currency_code { get; set; }
    
            public string X_line_item { get; set; }
    }

    Этот "Х" добавляет +80 к читаемости.

    Запостил: Moses, 19 Октября 2018

    Комментарии (49) RSS

    • Переведи на "PHP".
      Ответить
    • > { get; set; }
      Заставь дурака богу молиться — он и лоб расшибёт.
      Придумали, значит, умные дяди инструмент для сокращения бойлерплейта, а в результате получили ещё больше абсолютно бессмысленного текста. Это печально.
      Ответить
      • Вроде обычные проперти, чтоне так?
        Ответить
        • А зачем конкретно в этом случае они нужны? Чем отличается «public string X_login { get; set; }» от «public string X_login;», кроме использования модных ключевых слов и концепций? Применение какого-либо инструмента только из-за того, что с ним будет круче или современнее — рак IT-индустрии.
          Ответить
          • Тем, что проперти превращаются в методы под капотом и становятся частью интерфейса класса.
            Если ты завтра захочешь их переделать то кленты класса об этом не узнают.

            Если жы там будут филды, то тебе придется все перекомпилировать
            Ответить
            • Верно, я погорячился и сделал неверные выводы. Впрочем, необходимость класса с таким странным интерфейсом всё равно выглядит сомнительной.
              Ответить
              • Ты, холоп, так и собираешься дальше оставаться на этом сайте после того, как админ пидорнул меня за невинный гет?
                Ответить
                • @ADMIN-USEBOK хуесосина, ты-то куда лезешь? )))
                  Ответить
              • Там же еще и Model, кто знает, где оно используется. Может, фреймворк анализирует имена полей при помощи рефлексии и в соответствии с этим что-то там делает.
                Ответить
                • тогда лучше использовать атрибуты или как там они у вас назвается
                  Ответить
              • Я бы сказал что сомнительной выглядит необходимость писать весь этот бойлерплейт.
                Почему в C# нет датаклассов?

                Почему нельзя написать, например, так:
                public data class TransactionRequestViewModel
                {
                        public string property X_login;
                        public double property X_amount;
                }

                ?
                Ответить
                • А ограничить доступ как?
                  Ответить
                • не надо никакие дата бля класы - юзай Newton JSON и будет тебе радость юзать MongoDB :)
                  Ответить
                  • А зачем вообще юзать монгу? Ну мне просто интересно.
                    Ответить
                    • чтобы хранить документы и быстро их там находить по параметрам
                      а вот чем оно лучше Elasticsearch или SOLR хз
                      Ответить
                      • Не поверишь, но реляционная БД хранит и ищет ничуть не хуже, даже лучше.

                        Я три года трахался с монгой, из плюсов — только автоматический фейловер, если кластер настроишь. Лично я в ней что-то ценее структурированных логов побоялся хранить (там есть вид коллекции, который работает как циклический буфер), но люди пытались, и постоянно огребали.
                        Ответить
                        • >>Не поверишь, но реляционная БД хранит и ищет ничуть не хуже, даже лучше.


                          Реляционная БД требует описывать структуру таблицы, туда нельзя вот такой рендомный объект положить (кроме кейсов типа json field), а в монгу можно.

                          Я совсем не уверен что это плюс, но вот на мой взгляд разница именно в этом
                          Ответить
                          • > туда нельзя вот такой рендомный объект положить (кроме кейсов типа json field)

                            Для неструктурированного говна у PostgreSQL с незапамятных времён есть hstore. Правда, там вроде вложенности нет из коробки.
                            Ответить
                            • вот для вложенности

                              https://www.postgresql.org/docs/10/static/datatype-json.html

                              https://www.postgresql.org/docs/9.3/static/datatype-xml.html


                              но это не классический РСУБД
                              Ответить
                              • > https://www.postgresql.org/docs/10/static/datatype-json.html

                                Я про это тоже знаю, просто hstore ещё раньше появился. Ну и вложенность при желании можно имитировать ключами со структурой.

                                "pitushok" => "petya", "pitushok:kurochka" => "tsyplyonok"

                                ну ты понел.
                                Ответить
                          • В nosql обычно теряется какая-нибудь буква из ACID, вот и кажется, что они быстрее РСУБД...

                            А слабоструктурированную хуйню в РСУБД хранить всяко легче, чем сильноструктурированную в nosql.
                            Ответить
                            • >>А слабоструктурированную хуйню в РСУБД

                              нука, захрани мне в сраном mysql неструктурированну хуйню
                              Ответить
                              • Колонка под ключ, колонка под документ сраным блобом, индексы по функциям от документа (или мускуль в них не может?)

                                Вот и весь ваш nosql.
                                Ответить
                                • >>индексы по функциям от документа
                                  от блоба функции?;)
                                  Ответить
                                  • По результату выполнения функции над блобом. Типа достать поле name из json и т.п.
                                    Ответить
                                    • не знаю есть ли такое в Mysql (уверен что в 2008 году когда все сцались от nosql такого в mysql не было)

                                      в ms-sql, postgres и oracle такое точно есть

                                      причем там можно строить индексы по xml и json и (о, ужас!) xquery делать

                                      но тогда это уже не РСУБД а это уже и есть nosql
                                      Ответить
                                      • Но тут ты всё ещё можешь юзать join'ы и типизированные поля если они тебе нужны.

                                        А nosql'щик живёт счастливо до первого join'а.
                                        Ответить
                                        • >>А nosql'щик живёт счастливо до первого join'а.

                                          ну так обычно же их кобенируют, не?

                                          OLTP это рсубд
                                          а хрень кака-нить для поиска (уже вторичная, строящаяся по рсубд) может быть nosql
                                          Ответить
                                        • В чем бы ты хранил граф объектов?
                                          Ну например файловую систему, где посреди графа может расти другой граф с другими совсем свойствами (точка монтирования, reparse итд)
                                          Ответить
                                          • > файловую систему
                                            Общие атрибуты в обычной табличке. Специфичные атрибуты - в hstore/json в ней же или в связанных табличках, в зависимости от градуса пиздеца.

                                            З.Ы. Та же MFT вполне себе линейная табличка без претензий на иерархичность.
                                            Ответить
                                            • А иерархию ты как будешь делать?

                                              Найдешь мне все файлы с атрибутами в /c/porno ?
                                              Ответить
                                              • > иерархию
                                                Ну если без извращений с хардлинками, то parent_id. Если с хардлинками - то еще одну табличку для связи.

                                                Файлухи все равно не умеют искать на всю глубину, т.е. это решение не хуже.
                                                Ответить
                                                • >> то parent_id.
                                                  А найди мне при таком подходе одним запросом всех потомков определенного узла, чтобы его удалить?:) (чур WITH/ CTE не использовать, в сраных mysql их нет!)

                                                  На самом деле для хранения деревяшки в РСУБД есть https://en.wikipedia.org/wiki/Nested_set_model

                                                  Но там тяжело хранить доп атрибуты и двигать тоже тяжело


                                                  Я пытался тебе показать что бывают кейсы когда хранить граф объектов со случайными свойствами в РСУБД --- боль, а в nosql куда приятнее.

                                                  Другой вопрос что такие случаи бывают раз в 400 лет.
                                                  Ответить
                                                  • mea culpa
                                                    Mysql с восьмерки умеет CTE.
                                                    https://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQ L

                                                    Но наверняка пыхомускульщики об этом не знают.

                                                    Эй OBEH, ты не знаешь что такое "common table expressions"?
                                                    Ответить
                                                    • >>>"Эй OBEH, ты не знаешь что такое "common table expressions"?"

                                                      Честно? Без "Google" - нет. Мне эта поебень ни разу не потребовалась. Но сейчас изучу, чтобы впоследствии, в ходе срачей на этом же сайте, уколоть собеседника тем, какой я "умный".
                                                      Ответить
                                                      • Это ты что ли умный, таракан ты бля, подзалупный?
                                                        Ответить
                                      • З.Ы. foxpro - nosql?
                                        Ответить
                                        • >>foxpro - nosql?
                                          только в том смысле что там нет sql;)
                                          Ответить
                                        • Ох, оборвал бы я твои анимешные уши...
                                          Гандон ты ёбанный.
                                          Ответить
                  • В приличном обществе говорят про статически, строго типизированные языки
                    Ответить
      • { get; private set; }

        будет поприкольнее :)
        Ответить

    Добавить комментарий