Ukrywanie metod modelu przed widokiem Opcje

[coolos]

Witam,

mam pytanie w jaki sposób ukryć metody modelu przed widokiem? Chciałbym aby z poziomu akcji możliwe było wywołanie:

[PHP] pobierz, plaintext 
$news->add_news($id);
[PHP] pobierz, plaintext 

lecz żeby niemozliwe było to w widoku. Chciałbym aby widok, pobierał dane tylko z getterów.

Pozdrawiam

[Crozin]

[...] Z tym że ostatnio naczytałem się że ogólnie takie podejście nie jest ok, jeżeli chodzi o programowanie obiektowe i szukam innego sposobu.

Jakieś źródło tych "rewelacji"? Czy może dokładniej - co jest z tym nie tak.

[coolos]

Jakieś źródło tych "rewelacji"? Czy może dokładniej - co jest z tym nie tak.

Podam kilka źródeł wraz z cytowaniem:

artykuł 1

Normalnie klasy mapujące tabele w bazie i wykonujące logikę to powinny być te same klasy, niestety w J2EE wymyślono jakieś DAO i anemiczne encje, które służą tylko jako worki na kartofle, ups... dane, a nie posiadają żadnych odpowiedzialności i logiki, stąd też często programiści J2EE mają problemy ze zrozumieniem literki M skrótu MVC.

artykuł 2

Jednym z najczęstszych powodów powstawania anemicznych modeli domenowych jest sposób projektowania aplikacji w oparciu o wcześniej stworzony schemat bazy danych. To prowadzi to do tego, że model domenowy powstaje w skutek mapowania tabel do klas posiadających odzwierciedlone kolumny w postaci właściwości. Jedynym wyzwaniem dla niektórych osób może być modelowanie relacji, które w przypadku bazy danych są kluczami obcymi, zaś w przypadku obiektowego modelu powinny być relacjami do innych obiektów. Nie brakuje oczywiście przykładów, gdzie relacje w modelu domenowym tworzone są również w oparciu o klucze obce, co całkowicie zaprzecza obiektowemu programowaniu

artykuł 3

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

Ten post edytował coolos 13.06.2012, 16:55:51