Comments on: Anemic Domain Model Antipattern http://blog.centuryminds.com/2007/03/anemic-domain-model-antipattern/ Sat, 31 Jul 2010 22:40:32 +0000 http://wordpress.org/?v=2.6.2 By: Rubén Barroso http://blog.centuryminds.com/2007/03/anemic-domain-model-antipattern/#comment-187 Rubén Barroso Sat, 24 Mar 2007 12:59:45 +0000 http://blog.centuryminds.com/2007/03/08/anemic-domain-model-antipattern/#comment-187 http://jroller.com/page/JonathanLocke?entry=making_dao_really_work_with http://jroller.com/page/JonathanLocke?entry=making_dao_really_work_with

]]> By: Jesus http://blog.centuryminds.com/2007/03/anemic-domain-model-antipattern/#comment-188 Jesus Fri, 09 Mar 2007 14:21:27 +0000 http://blog.centuryminds.com/2007/03/08/anemic-domain-model-antipattern/#comment-188 Maaaaadre, un blog de frikies .. voy a dar cania (maldito teclado english). Bueno, a mi me hace mucha gracia cuando alguien fomenta los frameworks, las arquitecturas por capas con sus Controllers, sus Managers, sus DAOs, sus DTOs y luego se queja de que el modelo esta anemico. ?pero como no va a estar anemico??. Usamos frameworks que definen modelos procedurales sacando toda la logica del modelo y poniendola en otras clases ... es que no sus dais cuenta que los propios nombres: CONTROLLER, MANAGER estan diciendo: 'dadme objetos lo mas tontos posibles, que yo me encargo de todo'. Hay patrones como el Central Controller o como se llame que son totalmente anti OO ... pero molan. Lo de la Orientacion a Objetos esta muy bien, pero hay que asumir que cuando vendemos nuestro alma a un framework tenemos que pagar un precio, y parte de ese precio es volvernos procedurales, asi de claro. Por ejemplo, ?vas a meter una operacion transaccional en una clase de tu modelo?: pues no, para eso tienes un Manager. Hombre, puedes ser generoso y dejar a tu objeto del modelo que haga alguna cosita sencilla, pero cuando hablamos de transacciones o persistencia nos pasamos la OO por el forro. Y que quieres que te diga, puede que los frameworks sean un tanto embrutecedores, pero te hacen la vida mas facil. Disculpad acentos, enies y demas carencias Maaaaadre, un blog de frikies .. voy a dar cania (maldito teclado english).
Bueno, a mi me hace mucha gracia cuando alguien fomenta los frameworks, las arquitecturas por capas con sus Controllers, sus Managers,
sus DAOs, sus DTOs y luego se queja de que el modelo esta anemico. ?pero como no va a estar anemico??. Usamos frameworks que definen modelos
procedurales sacando toda la logica del modelo y poniendola en otras clases … es que no sus dais cuenta que los propios nombres:
CONTROLLER, MANAGER estan diciendo: ‘dadme objetos lo mas tontos posibles, que yo me encargo de todo’.
Hay patrones como el Central Controller o como se llame que son totalmente anti OO … pero molan.
Lo de la Orientacion a Objetos esta muy bien, pero hay que asumir que cuando vendemos nuestro alma a un framework tenemos que pagar un precio,
y parte de ese precio es volvernos procedurales, asi de claro. Por ejemplo, ?vas a meter una operacion transaccional en una clase de tu modelo?:
pues no, para eso tienes un Manager. Hombre, puedes ser generoso y dejar a tu objeto del modelo que haga alguna cosita sencilla,
pero cuando hablamos de transacciones o persistencia nos pasamos la OO por el forro.
Y que quieres que te diga, puede que los frameworks sean un tanto embrutecedores, pero te hacen la vida mas facil.
Disculpad acentos, enies y demas carencias

]]> By: Rubén Barroso http://blog.centuryminds.com/2007/03/anemic-domain-model-antipattern/#comment-189 Rubén Barroso Fri, 09 Mar 2007 11:48:48 +0000 http://blog.centuryminds.com/2007/03/08/anemic-domain-model-antipattern/#comment-189 Juanfri, solo decirte que el que ha escrito el post no he sido yo, sino Mikel. Luego cuando tenga un rato seguimos con la discusion de todas formas. Un saludo! Juanfri, solo decirte que el que ha escrito el post no he sido yo, sino Mikel. Luego cuando tenga un rato seguimos con la discusion de todas formas.

Un saludo!

]]> By: juanfri http://blog.centuryminds.com/2007/03/anemic-domain-model-antipattern/#comment-190 juanfri Fri, 09 Mar 2007 11:27:24 +0000 http://blog.centuryminds.com/2007/03/08/anemic-domain-model-antipattern/#comment-190 Hola Rubén, Muy bueno el post (y el blog en su conjunto!), voy a aprovechar que escribes en castellano :) para responder y para pegar un enlace al post de Martin Fowler que me parece que inició un poco el tema del Antipatrón: http://www.martinfowler.com/bliki/AnemicDomainModel.html En mi opinión el post de Fowler es desde una perspectiva purista con la Orientación a Objetos, esa perspectiva llevaría a incluir la lógica de negocio e incluso la de persistencia en las clases de dominio, lo que sería contraproducente para el desarrollo de las aplicaciones por el acoplamiento, dependencia tecnológica,... aunque la orientación a aspectos puede hacer que acabemos tirando por ahí. Tu enfoque me parece más práctico con las tendencias actuales en el desarrollo java, ese tipo de validaciones de negocio que tendemos a poner en los managers estaría muy bien aportándole algo de chicha a los objetos de dominio sin poner en peligros los beneficios de la separación en capas. Un Saludo. Hola Rubén,

Muy bueno el post (y el blog en su conjunto!), voy a aprovechar que escribes en castellano :) para responder y para pegar un enlace al post de Martin Fowler que me parece que inició un poco el tema del Antipatrón: http://www.martinfowler.com/bliki/AnemicDomainModel.html

En mi opinión el post de Fowler es desde una perspectiva purista con la Orientación a Objetos, esa perspectiva llevaría a incluir la lógica de negocio e incluso la de persistencia en las clases de dominio, lo que sería contraproducente para el desarrollo de las aplicaciones por el acoplamiento, dependencia tecnológica,… aunque la orientación a aspectos puede hacer que acabemos tirando por ahí.

Tu enfoque me parece más práctico con las tendencias actuales en el desarrollo java, ese tipo de validaciones de negocio que tendemos a poner en los managers estaría muy bien aportándole algo de chicha a los objetos de dominio sin poner en peligros los beneficios de la separación en capas.

Un Saludo.

]]>