ROTTWEILER: Pouzivam bezne (kazdodenni prace) Visual Studio ve Virtualboxu (host je Linux) - zadny problem, zadna pomalost. Pokud pojedes po lokale pres RDP na nejaky ESXi nebo podobne, vyjde to imho uplne nastejno.

ROTTWEILER: Obcas pres RDP ve Visual Studiu delam. Vynecham-li nepouzitelnost 2 monitoru pres RDP, tak jsem nemel problem. Samozrejme zalezi na tom, jaky mas spojeni na cilovy pocitac. Ale kdyz je to silna linka, tak ten rozdil neni moc poznat.

Zkoušel někdy někdo aplikovat vývoj na VPS? Např. měl Linux a měl Windows VPS, na které měl Windows a Visual Studio a přes vzdálenou plochu vyvíjel? Pokud, ano, bylo to použitelné?

BUTHRAKAUR: Jo.

MILL: Mam zkusenosti s WebSpark. Staci mit zivnostak a je to v pohode. Regnul jsem se pres web, za dva dny mi volal nejakej clovek z ceskyho MS, zeptal se me na par veci (ujistoval se, ze splnuju podminky) a den na to, jsem dostal mail a zaktivovany MSDN downloads.

Nemazte nekdo zkusenost, s prihlasenim do programu BizSpark z pozice programatora na volne noze ?

BUTHRAKAUR: jj cetl jsem, ale i tak je to pro me takovy zajimavy :]

ESY: je to zalozeny na pair programming + stridani, jestli se ti nelibilo "parovaci skupina" - ostatne na tom webu je popsany vsechno podstatny..

BUTHRAKAUR: co si podtim mam rpedstavit ? :D

nejdete nekdo na http://coderetreat.cz ? ze bychom pripadne udelali nyx C# parovaci skupinu :)

SMOKY: po konverzi na vlastni dto to jede v pohode, jen jsem si vsiml, ze do service reference v klientovi, ktera se generuje automaticky ze service se ted pridava jak entita, tak i nove dto, jak zamezim tomu aby se generovala i ta entita, ktera uz je zbytecna ?

MILL: Z principu by melo bejt jedno, na jaky platforme ta web service bezi. Pro predavani dat bych pouzil nejaky DTO, pouziti entit imho neni moc rozumny.

Dostal jsem se k jednomu projektu

klientska aplikace je WinForm + WCF client, psano v .NET 3.5
serverova cast je WebService + Linq to SQL opet .NET 3.5

je pozadavek prepsat to do Entity Frameworku a zatim narazim na same problemy, klient ma zustat na 3.5ce
pod .NETem 3.5 EF neincluduje fk sloupce do modelu, da se pres wcf klienta pripojovat k WebService na s .NET a EF ve verzi 4 a posilat cele objekty ?

Potreboval bych radu, nebo spis nejake nasmerovani, jak k tomu pristupovat.

Mam aplikaci napsanou prevazne v javascriptu. Po prvnim nacteni uz je vse resene jen pomoci ajaxu a nedochazi k zadnym refreshum. Na serveru bezi ASP.NET 4.0, kde mam vlastnorucne napsanou REST sluzbu poskytujici data, ktera jsou v MSSQL databazi. Pouzivam Linq 2 Sql pro nacitani dat. Nevyuzivam serverove MVC.

Tedka je pozadavek, aby se periodicky kontrolovalo, jestli na serveru nejsou nova data a pokud ano, tak je poslat, abych mohl aktualizovat zobrazeni a klientovi. V idealnim pripade bych chtel posilat jen zmenene hodnoty, ale to neni tak zasadni, jelikoz jde o intranetovou aplikaci, takze velikost dat na siti neni az tak zasadni.

Premyslim jestli pouzit System.Web.Caching spolu s SqlCacheDependency, ale nevim jestli je to dobry napad v souvislosti s Linq2Sql a spis to neublizi vykonu. Co myslite ?

BRAP242: vyreseno - v rootu webu je adresar kterej se jmenoval Administration - a to ho matlo ;-)

dotaz, lze nejak zautomatizovat pousteni urcite aplikace pod jinym uctem (typicky konzolovka, ktera potrebuje pro beh ucet s pristupem k databazi)? at nemusim pokazde zadavat jmeno a heslo, ale nejlepe mit jen nejaky bat na spusteni?

no covece z nejakyho duvodu to tak neni a vraci to 402

BRAP242: A to znamená co, „fungoval“? Naprosto typickým použitím routování v MVC je formát ~/Controller/Akce, ve tvém případě tedy pokud máš AdministrationController a v něm akci Index, bude pro toto URL volána při implicitním nastavením routování, aniž bys musel něco dalšího registrovat.

cus, mam dotaz:

jakou route mam zaregistrovat v ASP.NET MVC aplikaci, aby mi fungoval nasledujici odkaz:

http://localhost:36022/Administration/

dik!

VITI: no, pri takovy ty klasicky editaci vsech vlastnosti objektu/radku v gridu ztracis informaci o kontextu, proc ta zmena vznikla a nemuzes na ni dal reagovat, coz nekdy vadi. Napr mas v gridu seznam zakazniku, uzivatel zmeni X jak ho napadne, mimo jiny treba i cast adresy a pokud ma aplikace nejak reagovat napr. na prestehovani zakaznika, tak vznika problem. Reseni je jasne definovat operace, ktery se daji s danym objektem provadet (ty commands, jak jsem psal) a pro kazdou z tech operaci mit ten "detail" form, jak jsi psal. Pak ma aplikace sanci lip reagovat na ruzny situace/zmeny a treba i lip podporovat business.. ale to je tu asi spis OT :) Podivej se na CQRS, kde je tohle dovedeny do extremu.

BUTHRAKAUR:
a) uaa, pravda. Z nejakeho examplu mi tam jeste zustalo prevedeni kolekce na ToList(), kde vazba na db context zmizel ... pres ObjsectSet to jde ok. Dik.

b) tohle je jen demo-test, ale co myslis tim 'explicitnim stylem pres jasne definovany commands' ? Udaje needitovat v radku gridu, ale v 'detail' formu ci tak neco ?

VITI: jestli nactes entity z EF contextu, nahazis je do kolekce a tu kolekci/jeji prvky primo editujes v gridu, tak jde porad o tu samou entitu, ne? Nemel by byt potom duvod zpetne promitat nejaky zmeny a EF by si mel dirty entity sam odchytit, jestli teda umi dirty entity tracking podobne jako NH (EF nepouzivam). Jestli mi teda neco neuniklo a netransformujes to nekde na nejaky DTO...

Jinak pokud nejde o nejakou uplne nejprimitivnejsi aplikaci, tak bych doporucil needitovat primo v gridu, ale delat zmeny vic explicitnim stylem pres jasne definovany commands.