Implementations seems to be virtually identical, differing only in style, where the flyweight object is created and held by associated objects (containers: pointer objects, caches; factories; or cache-and-factory objects like Spring's BeanFactory) while the Singleton produces and carries the object within the class object.
Other than that, the difference appears to be one of intent: the Singleton expressly denotes one-and-only-one object for whatever reason (e.g. entry-points to be shared concurrently for caching, logging, accessing network resources where it's intended or simply ok to serialize access) while the Flyweight pattern is expressly to cut down on memory usage and does not strictly enforce the notion of one-and-only-one object.
Thursday, July 28, 2016
Monday, May 30, 2016
DAOs vs Repositories...
DAO = Repository
BO (Business Object) = Service
Bean = DTO != Domain Object
So the "Repository/Service" pattern roughly equals the "DAO/BO" pattern in my mind, just different nomenclature.
They imply layers of responsbility; but what those responsibilities are often comes down to personal style. E.g. I've seen the @Transaction decoration placed on the service (as some would argue transactions are a business concern) however I've also seen then defined in DAOs.
DTOs/Beans naturally tend toward placement in higher layers, e.g. an MVC controller* or a JSF view deals with these data bag abstractions, although the "bean" in JSF takes on some controller responsibilities vis-a-vis interacting with the BOs, indeed I've seen beans be called controllers in JSF.
BOs/Services may have the responsibility of translating the beans to domain objects and passing them to corresonding CRUD operations of the DAOs/Repositories; although I've seen where it's been convenient to pass domain objects (which DAOs/Repositories typically deal with at the persistence layer) all the way to the front-end. Likewise, I've also seen beans be passed from front-end to BO to DAO where convenient.
So while the assignment of responsibility among the layers isn't always straightforward, having responsibilities spread out, ala SRP, is useful so that one layer doesn't try to do too much.
* In Spring MVC the controller may set a "form backing bean" as a "model attribute" because it's through the model context that the view and the controller communicate.
BO (Business Object) = Service
Bean = DTO != Domain Object
So the "Repository/Service" pattern roughly equals the "DAO/BO" pattern in my mind, just different nomenclature.
They imply layers of responsbility; but what those responsibilities are often comes down to personal style. E.g. I've seen the @Transaction decoration placed on the service (as some would argue transactions are a business concern) however I've also seen then defined in DAOs.
DTOs/Beans naturally tend toward placement in higher layers, e.g. an MVC controller* or a JSF view deals with these data bag abstractions, although the "bean" in JSF takes on some controller responsibilities vis-a-vis interacting with the BOs, indeed I've seen beans be called controllers in JSF.
BOs/Services may have the responsibility of translating the beans to domain objects and passing them to corresonding CRUD operations of the DAOs/Repositories; although I've seen where it's been convenient to pass domain objects (which DAOs/Repositories typically deal with at the persistence layer) all the way to the front-end. Likewise, I've also seen beans be passed from front-end to BO to DAO where convenient.
So while the assignment of responsibility among the layers isn't always straightforward, having responsibilities spread out, ala SRP, is useful so that one layer doesn't try to do too much.
* In Spring MVC the controller may set a "form backing bean" as a "model attribute" because it's through the model context that the view and the controller communicate.
Subscribe to:
Posts (Atom)