в моей системе нет вообще никаких промежуточных данных и все нормально. Вы как то слишком все усложнили — проводка по складу это просто запись об изменении количества в ту или иную сторону. Каким боком там вообще всякие потребности и прочее.
остутствие промежуточных остатков позволяет простым запросом высчитывать обороты и остатчки и не заглядывать на какую дату каки промежуточные там данные. представте что у вас промежуточный итог на первое января мне надо посмотреть отчет за период с середины декабря по середину января. Могу я просто послать к БД запрос? в вашем случае врядли.
Кроме того это позволяет легко проводить документ=нты любым числом хоть задним хоть передним без пересчета остатков. прибил записи связаные с документом и добавил новые и все.
Я к тому что при нынешней копеечной стоимости железа так усложнять хранилище это экономия на спичках. И никакие nosql пока не переплюнут реляционные БД для учетных систем где данные реляционные по своей природе.
Не совсем понял цифры у вас количество балансов больше чем собственно документов?
Преимущество реляционного решения — вообще можно обойтись без хранения промежуточных остатков. Их можно моментально получить полным пересчетом. По таблице с числовыми полями даже mysql справится.
Кроме того ваша система ляжет на сложных репортах, уже проходил это на одном из проектов на CouchDb.
Пришлось переносить все на mssql
А какие проблемы? При субсветовой скорости с точки зрения летящего расстояние до вашего Трамвая сократится. Теоретически долететь можно и за пару дней.
Проблема — разогнать ракету до такой скорости.
Авторские права (если речь именно об авторских) неотчуждаемы по своей природе. Кто написал тот и автор.
Можно предъявить претензии на продук в смысле права владения но не на авторство.
Если она местами будет выглядеть и вести себя как MVC, местами как Razor Pages, а местами как непонятно что?
чего там непонятного? как запрограмируют так и будет себя вести. Нет никаких технических проблем сочетать в одном проекте MVC, Razor Pages и например WEBAPI.
И как что-то подобное будет реализовано в вашем конструкте?
там нет никакого конструктора. Вы вообще читали статью?
Все что было моделями теперь будет в одном классе вместе с обработчиками как принято в парадигме ООП.
При отсутствии нормальных мануалов
там несколько строк как. Какие нужны мануалы? Этой статьи более чем достаточно. Все остальное в официальных доках.
Ведь если оно так просто, то что например мешало самому Microsoft добавить такую функциональность?
Потому что стандартный фреймворк развиватся уже не будет. И майкрософту наплевать будет ли оно просто. А вот сообществу работающему над Core.Net не наплевать. Потому и появились Razor PAges/
То есть вы предлагаете уже имеющийся проект зачем-то «оптимизировать» и всё?
Проекты которые на саппорте все равно доделываются и переделываются. Почему бы по дороге их не упростить.
Сколько в вашем портфолио перенятых без посторонней поддержки легаси проектов?
Хватает. Но оно не в моем портфолиро в компании где я работаю.
Новые технологии обычно имеют хорошую документацию и комьюнити
Это наверно в вашей параллельной вселенной так.
Есть это у ваших «MVCRazorPages»? Или есть хотя бы шансы что это появится в обозримом будущем?
Это простое решение в несколько срок на основе уже имеющейся платформы. Там неоткуда взяться багам и там нечего поддерживать Там даже на гитхаб нечего выкладывать отдельным проектом.
Вы или не поняли написанного или не читали вообще а просто возражаете на все коменты подряд.
Чтобы прекратить флуд — покажите хотя бы одну ТЕХНИЧЕСКИ обоснованую проблему которая возникнет изза предлагаемого решения. Аргумент типа — у кого то не хватит извилин разобраться в несколькизхс строках состоящих из стандартных функций описанных в документации майкрософта — это не аргумент. Большинство статей на хабре гораздо сложнее.
Но всё равно надо признать что MVC это известный паттерн, а .Net MVC известная технология, которая легко понятна любому джуну и вполне себе имеет свои области применения.
Ну страница с бекендом а-ля Razor Pages джунам будет как раз понятнее.
Но вы вместо этого пытаетесь «перекрутить» MVC так, чтобы он стал похож на Razor Pages.
Ну так в стандартном фрейморке Razor Pages нет. А для приведенного решения ничего переделывать не надо кроме конкретного контролера то есть можно так доделавыть или переделывать существующий проект на стандартном нет.
Потому что вы протестировали вашу идею на плоской форме с двумя полями, но с такой формой и MVC справляется без проблем.
конечно справляется — проблема не в этом а в том что приходится использовать лишнюю прослойку — модель страницы смысла в которой нет. А на сложные страцы бывает и по несколько моделей городят.
Потому что новичкам нельзя будет дать мануал по MVC или Razor Pages, а надо будет объяснять как
и не нужно. Это решение для тех кто уже в теме но хочет оптимизировать свой проект.
Ну или представьте себе что вы по какой-то причине уйдёте из фирмы, а вашему преемнику придётся во всем этом разбираться без посторонней помощи…
когда кто то уйдет и придется разбиратся — это будет не самая большая трудность. Обычно в серьезных проектах основная трудность — это бизгнес-логика, ообенно когда проекту не первый год, поменялось три команды а заказчик и сам уже не помнить зачем применялся тот или иной алгоритсмм.
И вообще новые решения и технологии ща появляются каждый день — кто не умеет разбираться самостоятельно и осваивать новое тому в IT делать нечего.
а какие проблемы с этим в продакшене? И это не моя идея — Razor Pages в Core не я добавил. Я просто показал как можно это повторить в стандартном фреймворке.
В этом и преимущество разработки сообществом в опенсорсе коим ща является Core.Net — там не только те кому на курсах программирование рассказали что MVC это священная корова и по другому програмировать не моги или разрабы мелкомягких которым наплевать как на юзеров так и на других разрабов которые этим будут пользоватся.
на имеющиеся и/или запланированные на будущее альтернативы
Razor Pages и есть альтернатива на данный момент и пока я не услышал ТЕХНИЧЕСКИ обоснованных аргументов почему это будет работать хуже MVC. Компилятор сгенерит почти тот же код — удобства тут именно с точки зрения разработки — меньше индусского кода.
в MVC оно тоже присутствует только логика страницы размазывается по разным классам.
А вот в самом razor движке как раз с таким разделением не очень. начиная от запутаного синтаксиса (не сразу сообразишь где надо ставить @ а где нет) до разного рода Html хелперов которые затрудняют работу верстальщикам. Но это отдельная проблема самого движка как активном шаблонизатора а значит неизбежно содержащего код вперемешку с версткой. В этом плане Razor ничем не лучше PHP и JSP
Потому что Razor Pages и Razor Views, в том числе, отличаются наличием контроллера, и именно это отличие заметнее всего.
смысл в данном случае — реализовать аналогичный функционал. как будет называтся бекенд и в какой папке он будет не суть важно.
И да, объединить контроллер с «моделью страницы» (на самом деле моделью запроса) — совершенно не то же самое что от модели избавиться.
мы избавляемся от лишнего класса — посредника, чем упрощаем код и делаем его более прозрачным. Нет ни одного разумного аргумента (кроме тупого минусования) зачем нужен класс смысл которого переложить данные с одного места в другое в пределах одного приложения.
Ну технически Razor Pageв Core.NET строится поверх MVC, поэтому обязательно требуется использовать useMvc в Startup.cs
Но суть как раз в том чтобы упростить стандартный (не Core.NET а обычный .NET) MVC фреймворк где RAzor Page нет и вряд ли будет.. Потому что на нем пишут 99 из ста приложений. Не MVC решения очевидно не обладают недостатками которые исправляет решение аналогичное Razor Pages
откуда куча логики в разметке? Разметка тут вообще не меняется.
И зачем избавляться от контроллера? Мы избавляемся не от контроллера а от ненужной прослойки под названием модель страницы. По сути это то что иногда называют DTO (Data Transfer Object) — обычно это костыль подпирающий неудачную архитектуру.
А контроллер превращается в бекенд страницы соответствующий парадигме ООП и просто здравому смыслу.
Я так понимаю вы из поколения программистов считающих что MVC и веб это одно и тоже. Но лично мой мой многолетний опыт програмирования как раз убедил меня в обратном — MVC (в той релизации в которой он применяется в большинстве фреймворков) — самый неудачный паттерн для веба.
Откуда у нас вообще взялся контроллер, если у нас, вообще-то, Razor Pages?
Razor Pages это в Core. Суть в том как это сделать в стандартном ASP.NET MVC фреймворке. При желании конечно можно убрать контроллер — то есть переименовать его и может даже переместить, но смысла особого в этом нет.
Но это сразу же делает невозможным работу в двух окнах браузера!
не думаю что люди часто работают с одной и той же страницей в двух окнах (тем более это чревато работой с неконсистентными данными). Обычно работают с РАЗНЫМИ страницами одного и того же сайта.
Почему бы просто не добавить на страницу нужные скрытые поля?
потому что не все запросы отправляют форму. Это в WebForms вся страница бла формой и все запросы были POST
Это решение как раз и является «родным» для веба.
Нет — родным для веба является как раз stateless то есть проблема, а решения бывают разные. Согласен, в большинстве случаев тупо гоняют вереницу параметров.
Об это и речь, что можно делать и по другому, резко упростивши количество кода.
От человеко-подобных роботов и на земле мало пользы а что он будет делать в невесомости? Как будет двигаться если вообще будет двигаться самостоятельно. И вообще зачем ему там ноги? Они и людям там не особо нужны.
Намного проще если партией считать товар по одинаковой входной цене независимо от поступления. Это ж не лекарства что по сроку годности надо учитывать.
остутствие промежуточных остатков позволяет простым запросом высчитывать обороты и остатчки и не заглядывать на какую дату каки промежуточные там данные. представте что у вас промежуточный итог на первое января мне надо посмотреть отчет за период с середины декабря по середину января. Могу я просто послать к БД запрос? в вашем случае врядли.
Кроме того это позволяет легко проводить документ=нты любым числом хоть задним хоть передним без пересчета остатков. прибил записи связаные с документом и добавил новые и все.
Я к тому что при нынешней копеечной стоимости железа так усложнять хранилище это экономия на спичках. И никакие nosql пока не переплюнут реляционные БД для учетных систем где данные реляционные по своей природе.
Преимущество реляционного решения — вообще можно обойтись без хранения промежуточных остатков. Их можно моментально получить полным пересчетом. По таблице с числовыми полями даже mysql справится.
Кроме того ваша система ляжет на сложных репортах, уже проходил это на одном из проектов на CouchDb.
Пришлось переносить все на mssql
Проблема — разогнать ракету до такой скорости.
Можно предъявить претензии на продук в смысле права владения но не на авторство.
долго его там не держать. Толку никакого а для пропаганды и нескольких дней достаточно.
чего там непонятного? как запрограмируют так и будет себя вести. Нет никаких технических проблем сочетать в одном проекте MVC, Razor Pages и например WEBAPI.
там нет никакого конструктора. Вы вообще читали статью?
Все что было моделями теперь будет в одном классе вместе с обработчиками как принято в парадигме ООП.
там несколько строк как. Какие нужны мануалы? Этой статьи более чем достаточно. Все остальное в официальных доках.
Потому что стандартный фреймворк развиватся уже не будет. И майкрософту наплевать будет ли оно просто. А вот сообществу работающему над Core.Net не наплевать. Потому и появились Razor PAges/
Проекты которые на саппорте все равно доделываются и переделываются. Почему бы по дороге их не упростить.
Хватает. Но оно не в моем портфолиро в компании где я работаю.
Это наверно в вашей параллельной вселенной так.
Это простое решение в несколько срок на основе уже имеющейся платформы. Там неоткуда взяться багам и там нечего поддерживать Там даже на гитхаб нечего выкладывать отдельным проектом.
Вы или не поняли написанного или не читали вообще а просто возражаете на все коменты подряд.
Чтобы прекратить флуд — покажите хотя бы одну ТЕХНИЧЕСКИ обоснованую проблему которая возникнет изза предлагаемого решения. Аргумент типа — у кого то не хватит извилин разобраться в несколькизхс строках состоящих из стандартных функций описанных в документации майкрософта — это не аргумент. Большинство статей на хабре гораздо сложнее.
Ну страница с бекендом а-ля Razor Pages джунам будет как раз понятнее.
Ну так в стандартном фрейморке Razor Pages нет. А для приведенного решения ничего переделывать не надо кроме конкретного контролера то есть можно так доделавыть или переделывать существующий проект на стандартном нет.
конечно справляется — проблема не в этом а в том что приходится использовать лишнюю прослойку — модель страницы смысла в которой нет. А на сложные страцы бывает и по несколько моделей городят.
и не нужно. Это решение для тех кто уже в теме но хочет оптимизировать свой проект.
когда кто то уйдет и придется разбиратся — это будет не самая большая трудность. Обычно в серьезных проектах основная трудность — это бизгнес-логика, ообенно когда проекту не первый год, поменялось три команды а заказчик и сам уже не помнить зачем применялся тот или иной алгоритсмм.
И вообще новые решения и технологии ща появляются каждый день — кто не умеет разбираться самостоятельно и осваивать новое тому в IT делать нечего.
.
В этом и преимущество разработки сообществом в опенсорсе коим ща является Core.Net — там не только те кому на курсах программирование рассказали что MVC это священная корова и по другому програмировать не моги или разрабы мелкомягких которым наплевать как на юзеров так и на других разрабов которые этим будут пользоватся.
Razor Pages и есть альтернатива на данный момент и пока я не услышал ТЕХНИЧЕСКИ обоснованных аргументов почему это будет работать хуже MVC. Компилятор сгенерит почти тот же код — удобства тут именно с точки зрения разработки — меньше индусского кода.
.
в MVC оно тоже присутствует только логика страницы размазывается по разным классам.
А вот в самом razor движке как раз с таким разделением не очень. начиная от запутаного синтаксиса (не сразу сообразишь где надо ставить @ а где нет) до разного рода Html хелперов которые затрудняют работу верстальщикам. Но это отдельная проблема самого движка как активном шаблонизатора а значит неизбежно содержащего код вперемешку с версткой. В этом плане Razor ничем не лучше PHP и JSP
смысл в данном случае — реализовать аналогичный функционал. как будет называтся бекенд и в какой папке он будет не суть важно.
мы избавляемся от лишнего класса — посредника, чем упрощаем код и делаем его более прозрачным. Нет ни одного разумного аргумента (кроме тупого минусования) зачем нужен класс смысл которого переложить данные с одного места в другое в пределах одного приложения.
Но суть как раз в том чтобы упростить стандартный (не Core.NET а обычный .NET) MVC фреймворк где RAzor Page нет и вряд ли будет.. Потому что на нем пишут 99 из ста приложений. Не MVC решения очевидно не обладают недостатками которые исправляет решение аналогичное Razor Pages
И зачем избавляться от контроллера? Мы избавляемся не от контроллера а от ненужной прослойки под названием модель страницы. По сути это то что иногда называют DTO (Data Transfer Object) — обычно это костыль подпирающий неудачную архитектуру.
А контроллер превращается в бекенд страницы соответствующий парадигме ООП и просто здравому смыслу.
Я так понимаю вы из поколения программистов считающих что MVC и веб это одно и тоже. Но лично мой мой многолетний опыт програмирования как раз убедил меня в обратном — MVC (в той релизации в которой он применяется в большинстве фреймворков) — самый неудачный паттерн для веба.
Razor Pages это в Core. Суть в том как это сделать в стандартном ASP.NET MVC фреймворке. При желании конечно можно убрать контроллер — то есть переименовать его и может даже переместить, но смысла особого в этом нет.
не думаю что люди часто работают с одной и той же страницей в двух окнах (тем более это чревато работой с неконсистентными данными). Обычно работают с РАЗНЫМИ страницами одного и того же сайта.
потому что не все запросы отправляют форму. Это в WebForms вся страница бла формой и все запросы были POST
Нет — родным для веба является как раз stateless то есть проблема, а решения бывают разные. Согласен, в большинстве случаев тупо гоняют вереницу параметров.
Об это и речь, что можно делать и по другому, резко упростивши количество кода.
а в чем недостатки если страница для записи?