ASP.NET MVC

Та...да кажем следното:

Имаме в един солюшън:
1. App.DomainModel project
2. App.Repository project
3. App.Service project
4. App.Web project

Или на кратко т.н. "Hexagonal architecture"...или подобна...

Та, въпроса ми е:

Как си организирате ViewModel-ите?
1. Ипзолзвате AutoMapper м/у Domain Model-a и ViewModel-а.
2. Директно изполвате DomainModel-а в App.Web projecta.
3. Структурирате си DomainModel-а чрез ISP, т.е:
Пример:

                        interface IEmployeeBehavior

                            void Save(IEmployee employee);

                            void Delete(int id);

                            ... // Only behaviour

                        interface IEmployeeState

                            string Name {get; set;}

                            ..... // Only properties

           И после в App.Web

                       EmployeeViewModel : IEmployeeState

                        .... // щото нали в ViewModel-а ни требва стейта.

П.П. Само по темата моля, и ако някой няма какво да каже по техническата част - да не започваме да се псуваме и да си мерим заплатите, пишките, пичките и т.н.

П.П.2 Дееба, как се форматира текст тука...Ако някой знае, да сподели:-)
П.П.3 След многократни опити (може и от уиското да е ) форматирането отпада катго питанка:-)

Не го ли деприкейтнаха това MVC вече :)
Аз бих ти предложил да пробваш MVP (Model-View-Presenter), тука изглежда има интересни неща по темата - [линк]

Само според мене ли въпроса на арона е безмислен? Малко джава-дизайн-патърнско-студентско-нарсистичен-недочел ме се вижда.

БТВ, за кво ще дава трети класс емплойи в метода на интерфейс, който би трябвало да има референция към емплойи-то, и още повече защо не е стейта, койта така усърдно е отделил.

void Save(IEmployee employee);

Е, ти па го прие прекалено навътре примерния код.
Да, грешка е но идеята не е в това:-) Няма значение какъв тип параметър подаваш на метода.

Въпроса е друг.

Ако въпроса ти се струва безсмислен, значи не си пипал ASP.NET MVC.

MVP-то го пробвахме вече преди години. За десктоп се е утрепало.
За уеб - минусите са му много.

OK де, така или иначе ми се струва прекалено да разделяш стейт от бихейвиър.
Аз бих ползвал самите домейн обекти във view-то, като примерно имам за всяко ентити съответен CRUD мениджър.

Според мене е прекалено дизайн-патернско. Не виждам никакъв смисъл да разделям един проект в 10 солюшъна. Специално в МВЦ е лесно - генерираш си нещатата отдолу и ги консумираш, честно казано не виждам ползата от тези неща.

В тази връзка - които пичове са написали "Design Patterns" (което между другото е доста долнокачествена производна на оригинала Design Patterns за архитектура на Christopher Alexander) - трябва директно да се разстрелят. В смисъл наистина - просто тъпи парчета, глупави, яхнали маркетинг вълната. Леко умрели ще са доста по-полезни.

--
One day it will make sense.

Добре де, поне App.Web projecta няма ли да го отделиш от останалото?

Все пак може изискванията да включват: "Приложението да има версия на уеб и десктоп."? Тогава какво правим?

РЕСТ сървис с много леки клиенти за уеб и десктоп. Предимно джаваскрипт и много лек уинформс отзад. Dropbox според мене ако разгледате и изкопирате - е идеално между десктоп и уеб клиент.

--
One day it will make sense.

Ама нали пак ще отделиш клиента (разбирай уеб и десктоп) от РЕСТ сървисите?
Демек има WCF сървис на сървъра и отделно имаш уеб клиент и десктоп клиент.

В случая е същото...имаш бизнес логика на сървъра и всичко над нея я консумира...дали ще е уеб, десктоп, сървис...няма значение.

А каква е логиката във View-то да имаш следното примерно:

@Model.Employee.Delete(123) 

И друго, за да използваш unobtrusive client validation-а и евентуално Model validation-а на сървъра трябва да "нашариш" меко казано ентититата си с DataAnnotation атрибути, които ще станат на практика почти неизползваеми при друг клиент, например десктоп?

И в крайна сметка (не че имаш много мнения по въпроса) как ще го направиш/рефакторнеш?
То и заданието малко без конкретни спецификации, така извън контекст, е малко философско така че всичко е правилно като работи.

Освен това аз доколко съм бачкал със .нет съм оставал с впечатлението че всичко ти го прави вместо теб, RMB на ДБ таблицата, генерате уеб апп и си в джаза (образно казано). Което си е зле щото генерира и много глупости ама на теб ти е ясно това сигурен съм.

Съгласен съм с Гуру че патерните не са цел а средство, не трябва да мислиш са как да си направя аппчето така че да ползвам тоя и тоя патерн а трябва да го правиш възможно най - просто, покривайки изискванията ъфкорс.

Виж сега, въобще не става въпрос за дизайн патерни и т.н.
Например, използваш EntityFramework-а, генерираш си ентититата, използваш ги във View-to - чудесно. Но в момента, в който искаш да използваш unobtrusive client side validation-a какво правиш? Всяка една намеса в ентититата след прегенериране отива на майната си. Трябва да се отиде на варианта partial класове...абе бозата става страшна.

За мен например (а предполагам и за доста други) най-досадното нещо е проверката на инпута при клиента и на сървъра. Затова виждам някакъв смисъл в разделянето на state и behaviour. Да си шаря ViewModel-а с DataAnnotation атрибути колкото си искам, но да не закачам domain model-ите.

Да не говорим за това, че аз имам резерви към EntityFramework-a и всичко което генерира важна част от кода заради мен, ама това е друг въпрос.

Ами ViewModel тогава би трябвало да е окей. Лично за мене е леко дразнещо освен Model View Controller да имам и ViewModel, но ако така е по-лесно отколкото всички тези допълнителни неща - окей. В смисъл това си е доста популярен и валиден подход. Даже гледам в Силвърлайт средите тотално изчаткаха вече към MVVM модел.

--
One day it will make sense.

Е как е окей...не е окей...

Нека да не намесваме MVVM-а...

Под ViewModel разбираме MVC Model, който ще се консумира единствено и само от Web проекта, т.е. MVC проекта.

Domain model != ViewModel
EntityClass != ViewModel

Не знам, наистина. Технически на теория продавам неща за МВЦ и би трябвало да разбирам, но на практика нямам идея какво се прави в голям проект.

Според мене свали Orchard - това се прави от Microsoft (ASP.NET MVC CMS) и гледам фул-тайм се занимавам доста сериозни светила, включително ЛеРой (който е от най-добрите, уж) - там би трябвало да са го направили окей. Можеш някои идеи да свиеш от там.

[линк]

--
One day it will make sense.