The more I read, the more confused I am.
Note that all the question is related to how service and facades fit on the MVC pattern.
My understanding is that a Facade is not a super-smart object, it is simply a way of exposing a simple interface/api to perform a complex operation (example: perform a 10$ payment, it is a complex operation that involves a number of operations, but such complexity can be handled by a facade which will just call the corresponding object in a particular order...etc...)
Now, a service is a way to perform calls to several DAOs in order to get complex data structures (I am not too sure of this, but it is what I understand so far).
Question then is, what is the difference between a facade and a service? At the end of the day, the facade can perfectly access several DAOs in order to perform a complex operation by providing a simple interface, and a service seems to to something similar.
Same happens with transactions, I understand that a service is the place to start transactions, but I equally feel that they could also be placed on facades, after all, a facade may call several DAOs too.
So which stack would make more sense
controller-facade-dao
controller-service-dao
or maybe
controller-facadade-dao AND sometimes controller-facade-service-dao ??
A service is a way of writing an interface to an external system, such as a LDAP identity store, a payment gateway or an application management interface. It's a conceptual way of looking at the external system as a provider of useful services perhaps with internal behaviours rather than a passive lump to be operated upon.
A facade is a way of wrapping up anything (including a service) to present it nicely to another component. Facades are often used when:
A library or component is complex and your application needs only a subset of it. Your Facade presents the simplified API to the application
You are using several libraries or components and need to unify them, presenting a consolidated API to the application
The library you are using has a complex setup or set of dependencies, and the facade wraps all that up in the context of your application.
The bit that is really confusing is that you can (and often do) create a facade over one or more services. The service is the way that the component actually accesses the resource, and the facade is the bit which simplifies the component (such as configuration of options, connecting, etc).
If you write your own DAO, you probably will create your service just how you need, so writing a facade is an indication you did it wrong. If the DAO is built by a third party, and is more complex than your needs, then you can facade the service.
Now, a service is a way to perform calls to several DAOs in order to get complex data structures (I am not too sure of this, but is is what I understand so far).
I would say that the DAO is a design pattern all its own - see wikipedia.
If we contrast a DAO with a service, we have:
Level of API:
DAO: Fine-grained access to properties
Service: Coarse-grained access to services
Where implementation lies:
DAO: Mainly on the client, but storing data (without behavior) in the database
Service: Mainly on the server
How the interface is invoked
DAO: The client directly binds to the object in the same namespace and JVM
Service: The client is simply a stub for a network, cross-vm or cross-namespace operation
... the facade can perfectly access several DAOs in order to perform a complex operation by providing a simple interface, and a service seems to to something similar.
A facade could wrap up the DAO layer, but I don't really see this happening in a useful way. Most likely you need an API to access the individual properties of the objects, traverse the object graph and similar, and that is precisely what the DAO provides.
Same happens with transactions, I understand that a service is the place to start transactions ...
Absolutely, because the transaction is a service provided by the database and on another component or system
... but I equally feel that they could also be placed on facades, after all, a facade may call several DAOs too.
And in many ways the transaction manager service is a facade onto a much more complex backend implementation, co-ordinating the transaction on the web, application, database and other transaction-aware components. However this is already abstracted away by the transaction service implementation. As far as we, the user, are concerned, there is only the public interface.
This is, in fact, the conceptual point of these design patterns - to provide just the right amount of API to the user, abstracting the complexities of the implementation behind the iron wall of the component interface.
So which stack would make more sense
controller-facade-dao controller-service-dao
or maybe
controller-facadade-dao AND sometimes controller-facade-service-dao ??
The DAO is a kind of service to the database, but really the DAO is a design pattern itself.
If you write your own DAO, you should never need a facade.
Therefore the correct answer is:
controller - dao
Literally, Facade as the name suggests means the front face of the building. The people walking past the road can only see the facade, They do not know anything about what inside it, wiring, the pipes and other complexities. The face hides all the complexities of the building and displays a simpler friendly face.
In software terms, facade hides the complexities of software components behind it by providing a simpler interface, doesn't have the functionality of its own and doesn't restrict the access to the substsyem. Commonly used in Object Oriented Design.
Good examples are SLF4J - It is an api which is a simple facade for logging systems allowing the end-user to plug-in the desired logging system at deployment time.
A service is a public interface that provides access to a unit of functionality and always written to a specification. It needs to support the communication contracts (message-based communication, formats, protocols, security, exceptions, and so on) its different consumers require.
There is process services - encapsulation of business workflows , business logic service - encapsulation of rules/functions, data services - interaction with entities, data access management, infrastructure services- utility functions such as monitoring, logging & security. Services are mostly reusable, unassociated, loosely coupled units of functionality.
They are lot similar but depends on how you look at it.
The difference that I see, Facades are designed inside out. You look
at subsystem and design a facade to provide simpler access. Services
are designed outside in. You look at your customer/clients define a
contract and design the service.
My understanding of the classical GoF Facade pattern is that it's mainly intended to hide a poor design. As a rule of thumb, I would say that one should only need a Facade for legacy code.
I also think that this pattern made its way as a J2EE core pattern (Session Facade) mainly because the EJB spec (at least up to 2.x) inherently resulted in a poor service layer design.
Therefore, my answer to your question would be yes -- a facade is actually a service that hasn't been properly implemented the first time. If you need to hide the complexity from client code, it usually means that you only managed to provide a library, not a service layer; so, in this case, the Facade actually becomes your service layer.
On the other hand (assuming you have a decent domain layer), if you really need to provide the option of spawning complex flows with a single method call (something resembling macros/aliases), this would usually be better placed in the application layer and not in your core domain -- notice that I've switched layering terminology to domain driven design, where there's no "data access" or "service" layer, but "application", "domain", "infrastructure".
The first thing to note is that a design pattern is a description for a common (design) problem with a standard solution. In some cases there are several ways to solve the problem in a way that fits all requirements (f.ex. the Iterator and Singleton patterns have tons of different implementations; f.ex. check the work of Alexandrescu and compare it with the standard GoF solutions) and in some cases there are different patterns with the same (code) solution (f.ex. compare the class diagrams of the Composite and the Decorator patterns in the GoF book).
According to the GoF the purpose of the Facade pattern is to (literal quote):
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use.
Services have the intention of providing a user with a single higher level interface with a given functionality. That doesn't necessarily make it a facade, because a service is strictly speaking not by definition a unified interface to a set of interfaces in a subsystem.
But we can do better than that
Your question was if the patterns are "similar". If we consider them to be "similar" when pattern A equals B and pattern B equals A, then we should answer 2 questions:
Question 1: is a Service a Facade? A service should definitely expose functionality and is definitely a single interface that exposes this functionality. Functionality is normally decomposed into tiny pieces, so yes, services fit the underlying requirements of a facade. In other words: faced by the problem of exposing the underlying interfaces as a unified "service" interface, the facade pattern fits the requirements and is used to solve the service problem. The answer to this is yes.
Question 2: is a Facade a Service? Services are normally designed as reusable, unassociated, loosely coupled units of functionality. Thinking about communication between components is important for services, because they usually rely on a TCP/IP interface such as SOAP or WCF. This also means that functionality is often rewritten to fit the services paradigm more closely, which adds an implicit driven by performance requirement for the pattern. Facades don't have this extra requirement. In other words: a facade is not a service.
In exact terms, these concepts are closely related, but not the same.
But we can do better
This line of thinking raises the question if a service is an extended version of a facade? It is if a service meets all the requirements of a facade and extends on top of that.
If you read the description by the GoF closely, the answer is yes, that is: if one condition is met: The service has to expose subsystems. In reality, I think this condition normally holds, or you're over-designing your services - though strictly speaking I suppose this is not a hard restriction.
FACADE is a design pattern which solves the problem where there is a need for a unified interface to many interfaces in a subsystem so it defines a higher-level interface that makes the subsystem easier to use.
HOWEVER, A SERVICE provides access to resources or a set of interfaces/objects and may not necessarily simplify such an access. So you can employ the facade pattern to better design your service so you can save the client figuring out how to construct to use it.
Usually these terms are just used in their specific contexts.
'Facade' common usage context: simple API for complex parts of the application (like third-party libs)
'Services' context: unlock and surface the business entities in the system. (SOA, DAO, Security, etc)
You can view patterns as a language that evolves. It never seemed to be perfect end each pattern has it's own history and context. Sometimes classes could be viewed as Services and Facades at the same time, sometimes not.
For example: calling third party API by term 'Service' could be considered as misuse, because of the wrong context.
Before I try to answer, let me clarify something: there are three distinct things in enterprise applications - Facade, Service Layer, and Remote Facade.
Facade - while wrapping the subsystem(s), still is an object and UI (MVC) application usually lives in the same process. Thus, the communication is done in an usual OO manner: calling methods, reading properties, listening to the events.
Service Layer - when the business logic layer becomes mature and too complex for the MVC to interact with it directly, then Service Layer is put between them. Service Layer is an API that MVC uses as a wrapper of the business logic. It is not remote and is not required to use DTO since no wire is involved in the communication.
Remote Facade - (simply, any remote service) this is a hybrid of the Facade and Service Layer. Remote Facade starts existing when you want to expose some kind of wrapper over the system (and we call it Facade) as a distribution boundary. One of the reasons can be to allow several UI (MVC) applications use the same Remote Facade.
-
Comparisons:
Facade vs. Service Layer: they are similar since both they wrap subsystems. Difference is that Service Layer is more oriented on UI (MVC) application needs and exposes functions to simplify working with business logic. On the other hand, Facade is exposing functionality to simplify the business logic, but does not necessarily simplify the communication with UI (MVC) application.
Facade vs. Remote Facade (Service?): definitely different since Remote Facade must use DTOs as communication messages. Remote Facade will need some kind of proxy if you still want to use it as a regular object (properties, events); but the proxy will anyway use DTOs to the real object, i.e. Remote Facade.
-
Possible Flows:
controller-facade-dao - doubtful, but still possible. Facade is not usually used to wrap just DAL. There should be something more mature in addition as a subsystem. But, if the facade is part of the business logic, then yes, this is possible. Still the subsystem must be more emphasized. To me, DAL wrapping is not enough to call it Facade.
controller-service-dao - absolutely possible. Many remote services work directly with database through DAL.
controller-facade-service-dao - maybe, if you treat service as a subsystem.
I would add one more that can make sense:
controller-service [layer]-facade (part of business)-subsystem (e.g. accounting, business on its own)-dao - I'm sure you can translate this.
-
Remember, Service (or remote facade) can exist anywhere in the flow. That is just dictated by your distribution needs.
A service interface typically represents business concerns: perform some operation(s) and/or get some information. It wouldn't be unreasonable for the service provider to implement their service as a facade over internal back-end services - you'd never see this.
Your facade might wrap some general interfaces, which might include service interface(s).
For example, you might have service interface for a bank account (operation: Bank transfers money), and a local API to your local accounting records (I transfer money). You might introduce a facade over with a "move money" operation that uses the bank's service interface and manages your local checkbook as well.
It is the "context" that's matters. Facade and Service are not conflicting.
First I have never heard of "Service" and "Facade" in the context of MVC.
When people talk about Service, it is more about a system or component providing business-meaningful actions to outside world. You may sometimes see "Service" related to "Unit-of-work" (and hence, transaction).
Service is also used in the context of some layering approach of application: we have Service on top of DAO, for which Service will access data through DAO and business logic is put in Service layer, something like that.
Facade is usually used in the context of design pattern, and the focus is about "hiding complicated operations and expose it as a simple operation".
Facade may be or may not be a Service (a operation in Facade may not represent a Unit of work, but it is still a valid facade), similarly, a Service may or may not be a Facade (a Service may not hide any complicated operations but it is still a Service).
Again, it is all about the "context" that matters.
For example, when you are talking about layering of application, it is simply irrational to say "XXX is a facade to access DAO". Similarly, if you are talking about "design approach", it is more reasonable to say "XXX is a facade to multiple back-end" instead calling it a "Service" here (Although XXX is actually a Service).
Yeah, Facade and Service are not entirely unrelated. And some time we implement Service layer as Facade so that client is not bothered about to many details of the service. The more simpler the invocation/interface of a service is the simpler and easier clients code.
The Martin Fowler says...
A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations
So services layer is used at times as Facade.
Ref
Facade and Service Layer has kind of a similarity but both of them has two distinguished meanings. Let me explain this using a simple example.
Imagine we are asked to create new business application. This has a requirement of creating a check-in application but with more value added features and loyalty card features.
Lets say application should support Facebook and Foursquare check-in features if user wish to use. This feature is very much needed because some users are reluctant use several applications doing the same function or get rid of social connectivity.
to get a highlevel idea, refer sample api on the following link https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing
Above check-in API located at ABC facade is an example for usage of Facade.
It has our service API and also facebook and foursqure check-in capabilities based on client's selection. Facebook and foursqure APIs can have specific implementations (SOAP, Restful, etc. ) and security (OAuth etc.) requirements etc.
Satisfying one of these APIs (facebook, foursqure) requirements needs to fulfil different set of tasks. these will be different sub systems with in our check in requirement.
So facade's simplistic usage is to satisfy several sub systems triggered by one simple method
But if we consider our own API which is check-in API located at MngCheckinSvc. This is a service layer API. This is the API that contains our application's check in requirements. This is the API provide public access from your MngCheckinSvc to handle check-in requirement to application.
This will have complex inner behaviors but still most of them will be application specific logic implementations.
This API(MngCheckinSvc.checkin(....)) might access different set of DAOs, Internal APIs, may be other internal services etc. in order to fulfill merchant check-in with in the application.
Related
I have a problem with the domain-driven design architecture. Everything looks nice until I try to use REST. I should use the DTO instead of the entity on the frontend.
My architecture looks like:
My question is :
Should I use the web module and stick to it in the DTO? Is it the correct approach?
Domain Driver Design (DDD) approach was introduced on 2003, by a book with that name.
REST was initiated from the a Doctoral Dissertation named Architectural styles and the design of network-based software architectures that was only published on 2000.
It took some time for REST to spread, establish, and becoming popular. It probably reached "world-level popularity" roughly around ~2005-2008.
DDD referred mostly to isolated monolithic systems, or at least didn't cover aspects of cross system communication.
Therefore, even if you work "according to DDD", you will have to make your decisions - how to handle these aspects.
Reference: list of patterns introduce in the DDD book, with their relations:
You should see REST as just one of many "ports" allowing to reach your application layer services. REST, RPC, Websocket, etc. services would adapt & map input to application layer calls and vice-versa. At each service boundary you still have the flexibility to adapt responses, which does not have to have a 1-1 mapping with application service method responses, but could.
According to Implementing Domain Driven Design book by Vaughn Vernon, DTOs live in the application layer.
Ideally, the Domain models should be created by factories. So the factories can accept DTO and return an instance of the Domain model. Or you could use Builder pattern that accept DTO(s) to create the Domain model. This way you're domain model is kept clean from DTO and the Application layer in your architecture diagram should accept DTO(s) as parameters.
In your diagram, I am not sure what is the purpose of Application layer. Since what we call application should be the domain models.
Why it is best practice to call method implementation of another layer (e.g. call from Service to DAO layer) through interface?
Its n-tier architecture where n=1,2..n. The purpose of N tier architecture is to insulate the different layers of the application from each other. Lets take an example of web application. the GUI client(JSP/Thick client/MobileAPP etc) doesn't know how the server is working internally, and the server doesn't know how the database server works internally etc. They just communicate via standard interfaces. If you have change DB to JMS or to webservice, all you need to change is impl* classes without changes interfaces.
Separating application components into separate tiers increases the maintainability and scalability of the application. It does this by enabling easier adoption of new technologies that can be applied to a single tier without the requirement to redesign the whole solution.
In addition, n-tier applications typically store sensitive information in the middle-tier, which maintains isolation from the presentation tier.
This also helps in testing, maintaining and debugging easy.
Suggest you read here and here
Primary because then you can change the implementation of that layer without altering the client code.
Have a look at SOLID
The simple practice is abstraction .. you hide the actual implementation and just expose the definition...for example List is an interface and ArrayList and LinkedList are the implementations .... In the future you may need to change the implementation and with interface in place you will not change the client code ... you will change the implementing class without any effect on client
I haven't found any questions addressing this specific issue.
What is better: to allow Services (or facades) to access several DAOs (classes which talk to the database) or only other Services?
In other words, should I introduce inter-depencencies between different Service classes or is it better to make Service classes completely independent of each other by injecting more than one DAO (if necessary) to each Service class?
I found that both strategies will do the job, but I want to be consistent and make the application as modular and maintainable as possible.
I feel that allowing or forbidding a service to call another service or more than one DAO is subjective.
I try to avoid unnecesary code or odd couplings just to satisy some rule about layer-communication, and following basic OO principles of making simple, clear objects usually leads to a compromise.
If a service B needs another functionality already comprised in a service A then it should call it. I try to reduce dependencies among services and usually end up defining a small set of "basic" services that can be called from other services.
Creating a method in a service only to wrap a call to a DAO is pointless (in my opinion) and therefore I prefer to let services call as many DAOs as they need. Again, a service or a method with many DAOs indicates something that should be refactored or a data model that needs adjustment.
There's some opinion in this to be sure, but a true "service" method should be an atomic unit of work. If they're creating a web of interdependency calling each other back forth and sideways, clearly the invocations aren't performing atomic tasks. I see nothing wrong with letting a "service" use whatever DAOs it needs. Creating a set of "service"-CRUD methods abstracting the DAO which is already a collection of CRUD methods which is itself probably abstracting away the abstraction that is JPA, you can see how that might be one too many levels of non-functional abstraction.
This approach does sometimes lead you to build shared "business beans" that are in the domain rather than the service, that multiple services share. This is fine.
(Can you tell I personally think JPA has made the entire idea of DAOs obsolete and we should just use EntityManager in the service? :) )
I am a S/W developer working on a Java web application.
I have very limited knowledge of Java and want to understand my application architecture from a very high level in simple terms. Being a developer, I do not completely understand the big picture.
Can anyone help me understand this?
Each layer represents a place where some problems are solved is similar way, often using some particular libraries or frameworks. In trying to understand this work your way down through the layers. BUT, note that each layer hides the details underneath, you don't need to understand the details of lower layers in order to understand one layer.
So the Struts piece is dealing with the User-Interface related issues of understanding user requests choosing some business logic to invoke and choosing how to display the results back to the user. It doesn't concern itself with how the business logic works, that's the job of the next layer down.
By Business Logic I mean the Java (or other language) code that expresses the realities of a the customer's business. For example in a retail application we might need to work out discounts for particular volumes of orders. So the UI layer wants to display the price for a customer's order. It doesn't have any discount logic itself, instead it says to the business logic layer "Customer X is order N widgets and M zettuls, when can we supply and how much shall we charge" and the business logic figures out the pricing for this customer, which might depend on all sorts of things such as the status of the customer, the number things we have in stock, the size of the order and so on. The UI just gets an answer £450, to be delivered 16th September, and displays it.
That leads to questions such as "why separate the business logic to its own layer?" There are several possible reasons:
The business logic might be used by some completely different UI as well
It pre-exists, from some older system
Our brains are too small to think about UI and Business Logic at the same time
We have different teams working on UI and BL - different skills are needed
This same way of thinking follows down the layers. Th important thing when thinking about each layer is to try to focus on the role of the layer and treat the other layers as black-boxes. Our brains tend to be too small to think about the whole thing at the same time. I can almost feel myself changing mode as I shift between the layers - take off my UI head, put on my persistence head.
There's plenty of material "out there" about each layer. Suggest you start by reading up about one of them and ask specific questions if you get stuck.
Looks like a standard "enterprisy" application to me.
Interface
This app. is primarily intended to be used via web browsers by humans. This interface or UI layer (in a broad sense) is build using the MVC framework Struts. If you don't know MVC, then it's a good idea to read up on this term.
The app. also exposes web service interface, which is intended to be used by non-humans (other applications or scripts).
So, 2 kinds of interface is provided.
Business logic
Request coming from the 2 interfaces noted above, ultimately talk to the lower half (App. tier) to get some real job done. The actual process (calculating stuff, storing stuff and what not) happens here. Note also that this tier also talks to external systems (via Service Gateway) in order to complete the requests.
The reason they separated the system like this can vary. If it's a very simple, small app. then it doesn't pay off to have these abstractions, so it's probably a quite complex system. Maybe the app. tier is some legacy app. and they wanted to put some better UI on top of it. Maybe the app. tier and the web tier happened to use different technology stack. Or perhaps the app. tier is used by many other external systems. It also makes updating each services/replacing each services etc. easier, so maybe they are anticipating that. Anyways, it looks like a very common SOA type of design.
Not sure what else you might want to know. I see that the designer intends to use distributed cache in both tiers. All in all, it's a very common type of system integration diagram.
App Tier - Where the basic application logic resides (think of a basic console-only program).
Database - MySQL, Oracle... server
DOs - Short for Domain Objects. If anemic usually limited to getters/setters and can be synonymous with Entities (#Entity).
Data Access Objects - Objects using DAO pattern to fetch domain objects from the database. Could be considered equivalent as DAL (Data Access Layer) although this might not fit here. Usually uses a persistence/mapping framework such as Hibernate or iBatis.
Domain Model - Where Domain (domain being what has been studied/analyzed from requirements) Classes are packaged and associated (one-to-one, many-to-one, ...). Sometimes there are even composited in other container classes.
Core Application Services - Groups Services classes which could be equated to the Business Logic Layer (BLL). Biz services handle the Domain Model, Application Services are relative to the Application (methods don't manipulated Domain) and not sure what System Services are supposed to do. I'm also not sure what the distinction between Core and the Application Service block is.
Facade/Interface - This is where all the communication is done with other Tiers. It helps to fully understand interfaces and the Facade pattern.
TOs: Transfer Objects. Related to Domain Objects and used for transferring as the name implies.
Web Tier - All the logic added to make the application accessible from the Web.
Business Delegate: Block using delegation pattern? Here it apparently plays the middle man between Application facade and the Presentation Tier using TOs.
Model: Notion relative to the MVC pattern and variants. With JSF I know that beans are usually linked to JSPs. This model is to be distinguished from the Domain Model. It is created for the purposes of presentation and might contain information that has nothing to do with the data being manipulated in the application tier and is specific to the web tier.
View: Notion relative to the MVC pattern and variants. JSPs represent individual pages and use their own markup.
Session: Look up theory on sessions (necessary as HTTP is stateless).
ApplicationContext: Groups instances/settings that can be pulled into from anywhere. Often associated in the Java world with the Spring framework. To not be confused with UglyGlobalVar/singletons.
Front controller: Could be considered as equivalent to Controller of MVC although the Front Controller pattern appears to be more specific. Servlets are considered as controllers as they handle communication (GET, POST...) and coordinate the model/view. Not familiar with Struts but imagine that the framework implements classes to represent user actions.
Presentation Tier: Simply all of the logic used for outside presentation.
Filters: Can be used to filter requests, for example to redirect a request to a login page.
Feel free to add/correct this description.
I started experimenting with Spring Roo just recently. It does a very nice job helping one build a domain model with integrated persistence rather quickly. As it adds persistence functionality in aspects, I started think about the following question:
Roo adds finders (load an instance of a class from the database which meets variable criteria) in an aspect to the actual class/entity. In DDD this is IMHO the responsibility of repositories. Repositories are explicit classes which show up in the design. Of course as an aspect the repository functionality is hidden in an entity and is pretty much invisible.
So here is the question: Is an aspect a real substitute for a explicit repository class? Are there any downsides to the Roo AOP approach?
Adding finders to your domain classes feels more natural from a user's point of view but it mingles your layers. Grails uses the same approach by adding static finder*() save(), ... methods.
Apart from the aestetics it might have practical drawbacks when not used in web application setting:
Your domain classes are now tied to your database. If you transfer these objects to rich clients via RMI or HttpInvoker the client cannot and often may not use the find* methods because there is no session / database connection available on the client.
I generally prefer allowing domain classes to reference service layer interfaces to prevent an anemic domain model (http://martinfowler.com/bliki/AnemicDomainModel.html). This has its own set of drawbacks but at least provides a clear boundary. On the client the concrete implementation behind a service interface can then just proxy all method calls to the server (or just use a synamic proxy with spring remoting or sth similar).
So to answer your question: It might be a substitute but you should be aware of the possible negative consequences which make your domain classes (i.e. your core business logic) less portable between systems.
This depends on how complicated your applications persistence layer is and how much control you have over it. If your application is simple enough to be implemented via JPA, then it all could be handled via Roo aspects. However if you are mapping legacy tables or need advanced DB stuff, then you may find yourself in a situation where Spring-JDBC is the only way out and in these cases a repository/dao model may still be useful.
I consider it logical inconsistent (and a break of layer responsibility) to be mixing two persistence models and so as most of my applications requires such advanced DB constructs I stick strictly with a repository model.
I think adding repository methods to domain objects is bad design. The right place would be static methods in the domain class. But domain objects and their management are two different things that should be separated. I would prefer domain objects and repositories.
I guess the motivation was to achieve something Rails/Grails like with Java.