|
Repository & Service
|
|||
---|---|---|---|
#18+
Алексей КВладимир Путин-Ленинпропущено... буттон_клик?Да, если нет причин для усложнения. А какие есть причины для усложнения? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 12:43 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
skyANAАлексей Кпропущено... Да, если нет причин для усложнения. А какие есть причины для усложнения?См. "выделение класса" по Фаулеру. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 12:45 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
ИМХО многое зависит от бизнеса. В РЖД болото, бизнес дорос до своего потолка и Алексей не видит причин заморачиваться над чем-то. А у кого-то стартап и цель за 5 лет выйти на аудиторию в несколько миллионов. Ясен пень тут задумаешься над архитектурой и всем выше перечисленным. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 12:46 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
Алексей КskyANAпропущено... А какие есть причины для усложнения?См. "выделение класса" по Фаулеру. :) Алексей, когда предполагается нагрузка в 100 запросов в секунду, а через год в три раза больше, а через 3 года в десять, то надо изначально проектировать, а не потом. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 12:49 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
skyANA Алексей, когда предполагается нагрузка в 100 запросов в секунду, а через год в три раза больше, а через 3 года в десять, то надо изначально проектировать, а не потом. Не знаю как там проектировали изначально stackoverflow, но при возросших нагрузках выкинули нафик DI контейнеры, как вносящие огромнейшие тормоза. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 12:54 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
ЕвгенийВskyANAАлексей, когда предполагается нагрузка в 100 запросов в секунду, а через год в три раза больше, а через 3 года в десять, то надо изначально проектировать, а не потом. Не знаю как там проектировали изначально stackoverflow, но при возросших нагрузках выкинули нафик DI контейнеры, как вносящие огромнейшие тормоза. откуда информация? есть ссылка? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 12:56 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
Владимир Путин-ЛенинЕвгенийВпропущено... Тут правильней сразу смотреть в сторону старого доброго датаридера и ручного маппинга. а потом написать самодельный ОРМ, который потом заменить на нормальный. Ну эт когда докупят 100500 топовых серверов. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 12:57 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
ЕвгенийВВладимир Путин-Лениноткуда информация? есть ссылка? Есть. Не используют Dependency-Injection и IoC контейнеры. В коде практически всё построено на базе статических методов и классов. Аргументация - простота и улучшенная производительность. (Я бы сказал, что изначально без преимуществ ООП код строился и выработался стиль разработки, который менять теперь никто не хочет; безобразно, но однообразно .) что-то как-то... ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 13:24 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
ЕвгенийВskyANAАлексей, когда предполагается нагрузка в 100 запросов в секунду, а через год в три раза больше, а через 3 года в десять, то надо изначально проектировать, а не потом. Не знаю как там проектировали изначально stackoverflow, но при возросших нагрузках выкинули нафик DI контейнеры, как вносящие огромнейшие тормоза. А при чём тут проектирование? Репозиторий перестаёт быть репозиторием, если его создавать через new? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 13:29 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
Владимир Путин-ЛенинЕвгенийВпропущено... Не знаю как там проектировали изначально stackoverflow, но при возросших нагрузках выкинули нафик DI контейнеры, как вносящие огромнейшие тормоза. откуда информация? есть ссылка? Они сами про это рассказывают на конференциях. Как профилировали память и увидели какой трафик пораждают DI контейнеры. Также они не пишут тестов. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 13:31 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
А ещё можно посмотреть на ozon.ru, что был монолитным приложением и когда стало плохо, то распилили его на сервисы по аналогии с амазоном и получили профит. И подумать, а хотите-ли вы идти по такому пути: сначала накопить кучу технического долга, а потом ударно его отдавать, или может лучше воспользоваться чужим опытом и проектировать до, а не рефакторить после? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 13:35 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
Владимир Путин-Ленин Не используют Dependency-Injection и IoC контейнеры. В коде практически всё построено на базе статических методов и классов. Аргументация - простота и улучшенная производительность. (Я бы сказал, что изначально без преимуществ ООП код строился и выработался стиль разработки, который менять теперь никто не хочет; безобразно, но однообразно .) что-то как-то... Это личное мнение автора статьи, в скобках. Ребята просто взяли, сели и сделали нужный, масштабируемый и высоко-нагруженный ресурс, на котором все страницы доступны всем и который не теряет производительности когда заходит гуглебот. P. S. Вот ей Богу, как Симон и Борода в той серии критиковали рейтинг Moody`s :) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 14:13 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
skyANAТакже они не пишут тестов. Правильно делают! ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 14:14 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
Алексей КИли так: Код: c# 1. 2. 3. 4. 5.
Ой, спасибо. Оригинально. Я бы вот сходу наверное бы не додумался ). Читаю, пишу, читаю ... взгляд на все сейчас затуманен ... ))) А в целом UOW выглядит так как задумывалось Фаулером? Это была его идея? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 15:47 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
ЕвгенийВskyANAТакже они не пишут тестов. Правильно делают! У них процесс тестирования по другому выстроен :) Тупо не писать тесты - это ни фига не правильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 16:17 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
skyANAУ них процесс тестирования по другому выстроен :) Как? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 17:20 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
ЕвгенийВskyANAУ них процесс тестирования по другому выстроен :) Как? наверное, когда баги находят пользователи. сайт то для программистов :) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2016, 18:05 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
Иммануил КантЕвгенийВпропущено... Как? наверное, когда баги находят пользователи. сайт то для программистов :) примерно так :) сайт, где они находятся, не основной ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2016, 11:26 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
hVostt3. Для расширения (между EF и репой можно организовать свой слой умного кеша) спрошу здесь. у меня такая задача: 1. ASP.NET MVC-приложение - просто сайт для отображения данных. 2. Б о льшая часть данных - это некоторый архив, который желательно кешировать. Но есть данные, которые не архив, они меняются, и всегда должны показываться актуальными, задержка актуальности не допустима. 3. есть простой признак, как определить "архив/не архив" собственно вопрос: как лучше организовать кеширование, максимально используя стандартные средства, не изобретая никаких собственных велосипедов (некоторые запросы тяжелые, много всяких агрегаций/вычислений)? сам сейчас сделал так: для тяжелых запросов из архива сделал матвью, в сервисах на основе п.3 вызываю репо который либо для архива, либо для актуальных данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2016, 19:28 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
Иммануил Кант(некоторые запросы тяжелые, много всяких агрегаций/вычислений)? Подобные проблемы решаются добавлением избыточности. Например есть документ с табличной частью где построчно считается сумма (цена * количество) и есть сумма по документу. Чтобы не считать каждый раз сумму документа (сумма цена * количество всех строк) добавляют в шапку избыточное поле сумма. При каждом изменении пересчитывают, например в триггере. Точно также можно хранить любые расчетные параметры и обновлять при каждом изменении исходных данных. Т.е. вычислительная нагрузка во времени распределяется между вводом данных и запросами. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2016, 19:40 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
skyANAСервис - это бизнес-логика . Это как если бы Вы что-то делали, делали, проверяли, сверяли, получили результат (вот это сервис)... и на листочек записали (вот это репозиторий). Просто многие пихают первое в контроллеры, а потом задаются вопросом: а чем у нас сервисы от репозиториев-то отличаются? :) Вот тут созрел вопрос. Интересно как бы Вы реализовали. Есть Stage (один) и Step (ко многим) в базе. При создании Step на странице сайта нужно выбрать Stage из DropDownList. Вот модель Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Вот контроллер Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Видно что какая-то часть логики в контроллере. Вы бы оставили все как есть в контроллере или перенесли бы это в логику? PS. Сейчас у меня все это в контроллере, есть желание перенести в логику, но тогда придется менять DTO Step в бизнес логике, добавив IEnumerable<Stage>. Напомню что Stage (один) и Step (ко многим) в базе и не логично как-то в DTO Step иметь IEnumerable<Stage>. Заранее спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2016, 22:12 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
ЕвгенийВskyANAАлексей, когда предполагается нагрузка в 100 запросов в секунду, а через год в три раза больше, а через 3 года в десять, то надо изначально проектировать, а не потом. Не знаю как там проектировали изначально stackoverflow, но при возросших нагрузках выкинули нафик DI контейнеры, как вносящие огромнейшие тормоза.В каком году это было? Сейчас каждый уважающий себя DI/ORM/и т.п. применяет Emit-кодогенерацию - скорость мало чем отличается от рукописного кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2016, 05:16 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
skyANAИМХО многое зависит от бизнеса. В РЖД болото, бизнес дорос до своего потолка и Алексей не видит причин заморачиваться над чем-то. А у кого-то стартап и цель за 5 лет выйти на аудиторию в несколько миллионов. Ясен пень тут задумаешься над архитектурой и всем выше перечисленным.Таки не нужно сравнивать суровую бизнес-аналитику и миллионы запросов со сложностью, сопоставимой с поиском в хэш-таблице - в обоих случаях свои сложности и тонкие места. skyANAАлексей Кпропущено... См. "выделение класса" по Фаулеру. :) Алексей, когда предполагается нагрузка в 100 запросов в секунду, а через год в три раза больше, а через 3 года в десять, то надо изначально проектировать, а не потом.Но какое это имеет отношение к "буттон_клик"? :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2016, 05:39 |
|
Repository & Service
|
|||
---|---|---|---|
#18+
Алексей КЕвгенийВпропущено... Не знаю как там проектировали изначально stackoverflow, но при возросших нагрузках выкинули нафик DI контейнеры, как вносящие огромнейшие тормоза.В каком году это было? Сейчас каждый уважающий себя DI/ORM/и т.п. применяет Emit-кодогенерацию - скорость мало чем отличается от рукописного кода. Что же ты не приехал на Highload++ 2015 и не поведал им об этом? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2016, 10:15 |
|
|
start [/forum/topic.php?fid=20&msg=39190663&tid=1400730]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
93ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 209ms |
0 / 0 |