>>359366
Начни wpf и mvvm, структура сама выстроится (посмотришь в примерах)
>>359369
>mvvm
Спасибо. Еще какие нибудь советы кроме съебать?
бампецкий, вдруг еще кто что полезное подскажет
>>359612
Что тебе еще надо? Иди и пиши код, блядь
Зачем тебе хранимки в базе? Тебе c# дали, linq2sql дали, entity framework наконец.
Пишешь Data Access Layer, пишешь Business Logic Layer, качаешь Prism, пишешь ViewModel и View.
>>359625
>Зачем тебе хранимки в базе?
Что значит зачем? Хранимые процедуры зачем? А функции тогда зачем? Лал. За все остальное - спасибо.
>>359618
Пик стронгли рилейтед
> - SQL класс - полностью вся работа с SQL, все запросы и получения в базу и из базы
Почему бы не Entity Framework?
>>359640
Я хочу сделать отдельный класс, инкапсулирующий в себе полностью все, просто потому, что я хоть примерно представляю как это сделать, как его написать.
Но, честно говоря, я не настолько понимаю (точнее почти не знаю) что такое Entity Framework что бы с уверенностью сказать, что это то, что мне нужно.
Поэтому собственно и хотел что бы мне как дауну, на пальцах, объяснили что мне нужно, а я уж дальше сам, все подучу.
>>359366
В WPF тоже все эти DataSet, DataAdapter и прочее есть, только на формочки их кидать нельзя, пиши их в отдельный класс. Вручную ты пропишешь только связи между датасетами/запросами/коммандами и подключениями. Ну и биндинг контролов еще.
>>359625
Затем что ОРМ - тормозное говно и попытка выполнить через них джойн (без изъебов со stateless session всякими там) заканчивается зависанием на пару часов при наличии более чем 3,5 записей?
Процедурки, вьюшки, вычисляемые поля это оче удобно, разгружает клиенты и канал, дает хорошую производительность.
>>359700
Большое спасибо за ответ. Буду все таки в WPF писать, так что дельный совет. Спасибо.
>>359632
> зачем разбивать код на функции, когда я весь код могу засунуть в одну строку и выполнять его своим интерпретатором брейнфака
пофиксил свитерка
Что тут объяснять?
Объяснять, что SQL - декларативный язык для построения запросов к реляционной СУБД, а хп - процедурные расширения, которые ни в пизду ни красную армию?
Объяснять, что бизнес-правила по природе своей декларатины (ключевое слово правила)?
Объяснять, что процедурные языки программирования в принципе не предоставляют средств композиции своих примитивов?
Объяснять, что pl/sql банально проигрывает по своей выразительности обычным языкам общего назначения, а о разработке специализированных языков для задач предметной области на его основе просто не может быть речи?
Объяснять, что ограничение в 31 символ на длинну идентификатора - это какой-то наркоманский бред, особенно в контексте того, что индексы и отношения имеют составные идентификаторы?
Или может быть стоит объяснить, что РБД в принципе довольно убогий концепт для моделирования бизнес-задач?
Что моделирование длительных бизнес-процессов - process-biased, а не data-biased, как его воспринимают престарелые ораклаёбы, лепя тысячи флагов в своих таблицах или копируя по таймеру строки из таблицы несогласованных договоров в таблицу согласованных?
Объяснять то, что на хп, в отличие от чистого SQL тупо нет стандардов?
Рассказать про то, что использование хп фиксирует интерфейс работы базой и элементарный ad-hoc фильтр по 4 полям требует 2^4 возможных реализаций для обеспечения оптимальной производительности, а простенький join-projection хп пускают ко дну с отрицательным дифферентом без право на всплытие?
Объяснить, что ОП, не смотря на свой юный возраст, уже сатанист, без пяти минут еврей, будущий хаскелееб и нутром чувствует, что что-то здесь не так, хотя не может высказать формальных претензий, а тупое быдло пытается заставить его лепить триггеры на очередную говнопроводку в Р-схеме, родившейся в голове очередного 40-летнего тупого уёбка и реализованной студентами за ЖРАТ?
ТАК ЧТО ТЕБЕ ОБЪЯСНИТЬ, ТУПОЙ МУДАК, ОТВЕТЬ МНЕ ПОЖАЛУЙСТА!!!111?
или давай лучше ты по-тихому съебешь с моего /c/ на свой sql.ru, ты сэкономишь массу времени себе и мне, да.
>>359700
>Процедурки, вьюшки, вычисляемые поля это оче удобно
Пошел нахуй отсюда, пидор!
>что у нас ОЧЕНЬ хуево преподают и препод долбоеб
Дали им гугл. Ищи информацию, обмазывайся, читай книги, пиши программы, развивайся - не хочу, хочу ходить на занятия к окуклившимся преподам, хочу ныть и жаловаться на них и сосать хуи.
Да ебанный же ты по голове, две недели изучения исходников копрокубов дадут больше, чем джва года изучения быдлокодинга в вузе!
Преподы его плохо научили, блядь. Охуеть вообще.
Я конечно слышал, что в тематике одни сплошные бугурдуны, но думал если максимально корректно вопрос поставить, то можно будет этого избежать, но нихуя.
Ладно, поясню:
>>359767
>ТАК ЧТО ТЕБЕ ОБЪЯСНИТЬ, ТУПОЙ МУДАК, ОТВЕТЬ МНЕ ПОЖАЛУЙСТА!!!111?
Я сразу написал - НИХУЯ НЕ ЗНАЮ, любые предложения и советы, с интересом рассмотрю. Я ни от кого не требую и не прошу ничего. Если есть возможность - я буду только благодарен. Да я читаю книги, да я гуглю, но такой поток информации что я не успеваю все понимать, а много забывается, если его не используешь. Я понимаю, что с высоты своего полета, ты охуенный бетмен и можешь тут всех хуями обкладывать, но если у тебя бугурд по любому поводу, может тебе стоит самоутверждаться на тех, кто может тебе ответить? А я - с интересом перечитаю твой ответ, мне кажется в нем есть полезная информация. Спасибо.
>>359779
>Дали им гугл. Ищи информацию, обмазывайся, читай книги, пиши программы, развивайся
Я еще раз повторю - я написал выше - я полным ходом читаю, гуглю. Но к сожалению, не все гуглится, не все я успеваю прочесть, понять, правильно применить. Поэтому я пришел сюда и спрашиваю совет. Да учусь, да я знаю от ньюфагов тут припекает. Но я по крайней мере просто спрашиваю совет, а не прошу решать за меня лабы или что то подобное. Я все делаю САМ, полностью сам все пишу, мне был нужен только совет по тому в чем я не уверен. Просто до того, что бы все выглядело как надо. Вот и все. Зачем бугурдить? Я разве кому то что то доказываю? С кем то спорю? У кого то что то выпрашиваю? Так почему у вас пердаки в клочья постоянно? Нихуя нельзя спросить, что бы не набежали попоболящие.
И кстати про хранимки, я взял ВНЕЗАПНО базу большого коммерческого приложения и охуел от того, какой там пиздец внутри. Писали наверняка такие же, бугурдуны, как некоторые тут. И что бы избежать такого пиздеца, я и задаю тут глупые вопросы.
>>359789
В вашем сообщении слишком часто употребляется солов "бугурд"
Какого года твое коммерческое приложение?
>>359789
>Я конечно слышал, что в тематике одни сплошные бугурдуны
Лол, тут все всех поливают говном, даже небо, даже Аллаha. Больше чем в /b/.
>>359791
>Какого года твое коммерческое приложение?
Первоначально - 2008, но его постоянно модифицируют, обновляют.
>>359700
>Затем что ОРМ - тормозное говно и попытка выполнить через них джойн (без изъебов со stateless session всякими там) заканчивается зависанием на пару часов при наличии более чем 3,5 записей?
Пруфы в студию.
Примерный гайд:
1. Идешь на http://compositewpf.codeplex.com/, качаешь оттуда документацию и quickstarts
2. Читаешь доку, реализуешь shell и бутстраппер. Нугетом качаешь prism и unity https://unity.codeplex.com
В шелле важно определить регионы приложения, которые будешь юзать позже. В бутстраппере - конфигуришь module сatalog и ioc-контейнер
3. После того, как у тебя хоть что-нибудь запустится, делаешь свой первый модуль. В нем создаешь View, который регистрируешь в регион на шелле. Инжектишь в него ViewModel с помощью Unity. 1 модуль - 1 проект в солюшене
4. Пишешь классы модели. Обычно 1 таблица в бд = 1 класс модели, но it depends. В классах модели только бизнес-логика, никакой работы с бд. Для начала можно просто написать набор свойств, которые дублируют поля в бд.
5. Для каждого класса модели пишешь сервис-класс, который будет слоем взаимодействия с бд. Сюда идут методы Add(Model model), GetById(Guid id) и т.п. Можно написать тут вызовы к хранимкам, можно взять какой нить ОРМ (сам пока не пользуюсь). Модель и сервисы лучше держать в отдельном проекте.
6. Инжектишь во ViewModel нужные сервис-классы, пишешь в нем логику взаимодействия с UI. ViewModel должна наследоваться от NotificationObject. Чтобы заслать данные во View, юзаешь RaisePropertyChanged, чтобы получить действия юзера из View - DelegateCommand.
7. Когда модулей становится больше 1, разбираешься с EventAggregator, пишешь на нем взаимодействие между модулями.
>>360059
Ты вбросил какуюто хуйню, без пруфов идешь нахуй.
>>360158
Без обид бро, но ты слишком услекся. Инжект инжектом погоняет, а ОРМ осилить времени не хватило.
>>360168
Проект, над которым работаю, достался от аутсорсера. Много легаси. Мигрировать все на орм долго и муторно, + есть подозрение что производительность таки просядет (много сложных запросов).
В Prism на IoC много что завязано, да и разбираться с тем же unity не нужно долго. Код же от использования контейнера становится намного понятнее, если немножко разберешься.
EF в планах на изучение, да. Опыта у меня немного, 1.5 года, так что я не всезнайка-сеньор пока. Но даже если юзаешь ОРМ, базовые знания sql не помешают.
>>360170
>Для начала можно просто написать набор свойств, которые дублируют поля в бд.
Ну ты же понимаешь, что это чисто мартышкин труд?
>>360172
Для начала сойдет, просто и понятно. Когда придет понимание, какие бизнес-правила нужны, в этих классах появятся методы.
Альтернатива какая? Автогенерация?
>>359366
Много читать а экспериментировать, анон. В процессе задавать вопросы. Никто тебе не сможет пояснить по хардкору в двух словах за структуру аппликухи, это элементарно невозможно - во первых все приложения разные и выполняют разные задачи, во вторых по поводы структуры конкретных все всегда срутся, не умолкая - это нормально. В итоге тебе помогут: опыт, знание различных мнений, быть в тренде (лол), книги, тусование на форумах, чтение новых статей и всё такое.
Всё, что тебе могу сказать конкретного - ты движешься в правильном направлении, хотя бы задаешь подобные вопросы. Дерзай в общем, пиши код, смотри че получается и думай, что можно сделать удобней.
>>360184
Автогенерация не даст нужных тебе методов, насколько я понимаю.
+ у меня вот в таблице бывает по 150 полей. Энтерпрайз, мать его. Могут регулярно добавляться новые. В проге нужно полей 10, грубо говоря. Мне проще написать ручками POCO-класс, чем сгенерировать монстра на 150 полей и потом искать в нем нужные.
Все зависит от задачи. Плюс описанного мной подхода - можно за выходные написать каркас и перейти к полезному для юзера коду. После n-итераций с добавлением новых фич у него будет готовое приложение и, скорее всего, возникнут идеи / вопросы о том, что можно улучшить / упростить.
Prism несложный. Unity несложный. log4net несложный. EF думаю тоже несложный. Но чем больше таких "несложных" либ в проекте, тем сложнее будет начать.
Алсо, мое мнение не какая-то 100% истина. Я поделился своим опытом. Расскажи, как бы сам сделал.
>>360188
Да всё правильно ты говоришь, спорить тут не о чем.
У меня во главе угла стоит скорость разработки, поэтому я сгенерю класс хоть из 1500 полей, ради одного поля. Вообще я не повторяю код. Если я создал в БД таблицу, зачем мне её переписывать еще и на сишарпе. Мне за это не платят.
>>360188
> у меня вот в таблице бывает по 150 полей. Энтерпрайз, мать его. Могут регулярно добавляться новые.
что это за дерьмо блядь, откуда там в таблице новые поля ёбана? тока domain-first-model тока хардкор
>>360223
Мало того, даже количество полей в доменной модели может стать очень-избыточным, для рожи в таком случае используется одата
мимо-написал-свою-реализацию-одаты
>>360191
>я сгенерю класс хоть из 1500 полей, ради одного поля. Вообще я не повторяю код. Если я создал в БД таблицу, зачем мне её переписывать еще и на сишарпе.
говноед блядь, хорошо что вас обезьян не допускают за километр до реальных систем
Спа программач! Очень нужен совет от толковых ребят. Сам я студенота и в коддинге ньюфажина, поэтому остро нуждаюсь в севете продвинутых анчоусов.
Суть такова - я хочу написать (точнее уже начал) небольшую программку - есть SQL база, ну допустим с работниками которым начисляется зарплата в зависимости от количества часов, все операции происходят в этой базе (то есть база полностью в себе имеет весь набор необходимых хранимок\функций), и есть простенькая оболочка, написанная на C# (на формах или на WPF я пока не решил).
Теперь вопросы:
1. Как по умному организовать структуру такого приложения? Я хочу разбить его на такие классы:
- SQL класс - полностью вся работа с SQL, все запросы и получения в базу и из базы
- Messages класс - отвечающий за все взаимодействия с окнами между собой, передачу информации туда и обратно
- Main класс - главный гласс, который будет полностью содержать в себе всю необходимую логику и связывать два предыдущих класса.
Мне это видится так. Может кто то подскажет - правильно это или нет?
2. Я уже начал писать базу, все таблицы готовы, а вот для написания функицй, думаю - может стоит базу уже привязать к оболочке, что бы было легче понимать какие функции уже готовы, а какие еще надо дописать? Или пока база не будет готова на 100% не стоит этого делать? Как обычно делают в таких случаях?
3. Все никак не могу понять - в WinForms, есть такой контрол - DataSet - раньше я просто подвязвал к нему таблицу, но мне кажется это не совсем правильно, хоть и очень просто. Наверно за отображение таблицы должен класс SQL отвечать, но не понимаю, не прописывать же все вручную? Короче - как правильно сделать - хочу что бы таблица отображалась на форме, что для этого использовать - ДатаСет или как то хитровыебанно отображать самому, потому что датасет, создает какой то мутный объект и его не сильно то и поменяешь.
Пацаны, только говном не закидывайте. Я хочу что бы как лучше сделать, научится, может еще, не дай бог, придется вместе работать. Инбифо - книжки умные читаю, стараюсь.