Design rules - Model View Presenter [ MVP ]

Vsebina je povzeta iz Blog-a { http://kjellsj.blogspot.com/search/label/CAB }
Točke so zelo konkretne/uporabne.
Sem mnenja, da se jih moramo do neke mere držati in upoštevati pri našem delu.


1. All views should have a XxxView suffix: TaskView/ITaskView

2. All presenters should have a XxxPresenter suffix: TaskViewPresenter

3. Let the presenter do all use-case processing, but keep GUI control details in the view

4. All presenter methods called by the view must start with OnXxx() as they are events by design (MVP)

5. Calls from the view to the presenter should be kept at an absolute minimum, and used for "event" type calls only: _presenter.OnViewReady();

6. It is FORBIDDEN to use the presenter reference to access the model or services directly, no return values from presenter methods

7. Calls from the presenter to the view MUST go via the interface only

8. No methods in the view shall be public unless they are defined in the interface

9. It is FORBIDDEN to access the view from anywhere but the presenter, except for loading and showing the view from the CAB ModuleController

10. The interface methods shall have long meaningful names (not "SetDataSource") based on the domain language of the use-case

11. The interface should contain methods only, no properties - afterall the presenter drives the use-case by calling methods, not by setting data

12. All data in the MVP component should be kept in the model, no data should exist only as properties of UI controls

13. The methods of the view interface should not contain UI control name references (e.g. AddExplorerBarGroup) as this makes the presenter know too much about the implementation technology of the view

14. Stick with domain naming in the view methods (e.g. AddTaskGroupHeader), this makes the code easier to understand and the tests self-describing

Publikacija in subskripcija na dogodke - View->View

V mnogih primerih so forme med seboj povezane -- najbolj pogosto gre za Parent->Child relacijo.

Ker so vse forme znotraj SCSF/CAB popolnoma samostojne je eden izmed načinov obveščanja s pomočjo Eventov.

Za primer vzamimo povezavo med formo za pregled vseh postopkov in formo za urejanje postopkov. Terminologija za lažji prikaz je sledeča :

• forma za prikaz postopkov : A
• forma za urejanje postopkov : B
  

Forma A : Gre za zelo enostavno "browse" formo .. na kateri si prikazani vsi postopki.
Na voljo imamo dve akciji :

• a) dodaj nov postopek

• b) spreminjanje obstoječih postopkov

Obe akciji se prikaže forma B na kateri imam možnost urejanja postopka ...
V primeru smo na formi B spreminjali podatke in smo formo B tudi zaprli [ shranili podatke ] so podatki na formi A ostali nespremenjeni .
Če želimo, da se podatki osvežijo moramo implementirati :

* Event Publication
* Event Subscription

V našem primeru je forma A - poslušalec (subscriber) forma B - publikator.

Korak 1. [SCSF]










Vnesemo ime našega Eventa, scope in tip eventa [ lahko je katerikoli objekt ~]













Generirana koda v presenterju









Naslednji korak 2. pa ponovimo na vseh formah za katere želimo, da se "naročijo" na naš Event.






















Generirana koda v presenterju

Kako dobimo filtrirane podakte iz grida.

Namesto poste uporabimo poljuben objekt

PostaList list = PostaList.NewEntityList();
for (int i = 0; i < ASPxGridView1.VisibleRowCount; i++)
{
list.Add((Posta)ASPxGridView1.GetRow(i));
}

upam da se bo sedaj videlo v redu. Namesto PostaList se uporabi Drug seznam, lahko tudi Lista.

Many-To-One mapping attributes - Persistance problem

Pravilno nastavljen atribut v poslovnem razredu tipa PBBusinessBase.

Če se želimo izogniti izjemi : "Index out of range Exception", ki je posledica zapisovanja poslovnega objekta v bazo moramo obvezno dodati dva polja v atribut ManyToOne.

Primer pravilno nastavljenega atributa :

[ManyToOne(0, Name = "Procedure", Class = "WF.Library.WFProcedure, WF.Library", Insert = false, Update = false)]
private WFProcedure _procedure;

Do izjeme pride zaradi tega, ker želimo v bazo zapisati tudi property _procedure -- kar pa ni v redu saj gre za referečni property in zapisovanje teh podatkov bi bilo redundantno.

Many-To-One in binding na formi

Uporaba povezanih objektov za binding na formi.

Objekt WFBusinessEvent ima povezavo Many-To-One na objekt WFBusinessStep.
V samem objektu je vezan objekt shranjen kot property.



























Če želimo vezani objekt tudi bindat na formi je postopek sledeč :

1. definiramo nov property tipa [npr:WFBusinesStep ]
   
   
2. Kreiramo BindingSource
   
   
3. Nastavimo DataSource [polnjenje podatkov] v metodi Initialise
   _BSBidning.DataSource = ReferencedBStep;

• 

Registracija Service-ov

Za vsak Service posebej, tudi če je generičen je potrebno narediti interface, ki deduje od ISelectService interface. Ter implementacijo ki deduje od SelectService<>, brez implementacije kode, samo definicije razredov.

Many-To-One mapping MultipleForeignKey

[ManyToOne(0, Name = "BusinessStep", Class = "WF.Library.WFBusinessStep, WF.Library")]
[Column(1,Name = "BusinessStepId")]
[Column(2,Name = "BusinessprocedureId")]
private WFBusinessStep _businessStep;

TreeView za uporabo menija [module]

Implementacija MENIJA --> TreeView kontrole

Otvoritev ...

Danes je dan D :)