I often hear the term "Stateless" and "Immutable". For example, HTTP is a stateless protocol, and a String object is an immutable object. But I have a hard time grasping the difference between the two. When I create a stateless object, it doesn't store any "state" data internally. And if I create an Immutable object, it mean its will never change.
http://en.wikipedia.org/wiki/State_(computer_science)
http://en.wikipedia.org/wiki/Immutable_object
Doesn't that mean the same thing?
Since the immutable object doesn't change, by definition it cannot have a state. It is what it is forever. And if an object doesn't have state, it cannot be mutated (by definition). Thus, aren't all stateless object immutable and immutable object stateless?
What could be an example of mutable stateless object or immutable stateful object?
The context is important and there are two unrelated concepts here.
"HTTP is a stateless protocol" means that each request has no implicit knowledge of other requests, including any previous request sent by the same client. This is different from a protocol like FTP or SMTP where a connection is established and then different commands are sent - each command/request is "associated" to the same client/connection. Of course state/tracking is added back via. cookies and tracking URIs, and even pipelining - but the point is that each request is "new" and "separate" in the HTTP protocol.
"String is an immutable object" means that that particular object's data will always be identical to what it is now in every observable manner (this also implies that observable attributes can't be changed). Some purists might argue that it has deeper implications than this, but in practicality is is about observable attributes - the issue becomes more complicated when immutable objects can "contain" mutable objects.
(And yes, by technicality, an object with no allowed data - or state - can't be updated and is thus "immutable". However, once again, context is important and it's odd to talk about Fangs on an Elephant or a Trunk on a Tiger.)
Edit: Difference between the two
An object that has no state is stateless. All stateless objects are immutable (because there is nothing to mutate); this is a tautological technicallity. An object can have state and still be immutable - however, an object with state (immutable or otherwise) can no longer be considered stateless. As per comment on the linked answer: "[an immutable object] has exactly one state", the initial state.
— from my comment
No. They do not mean the same thing.
An Immutable Object can never change. That doesn't mean the data contained in that Object can't indicate State. It just means that if you want to represent a change in State, you need to create a new Object.
Stateless means that there is no state.
I'd say it is the same thing in some contexts, but we focus on a slightly different aspects.
When people say that "stateless" means it has no state, it makes me laugh. Of course it has some state from some point of view, e.g. stateless service can be backed by complex graph of objects (dependency injection). The thing is network protocol has slightly different meaning of the "state": it is something that depends on previous request/response. But immutable service doesn't depend on previous calls too, by definition.
"Stateless" doesn't always related to HTTP-protocol, the same term we can use to argue setters in service objects in your shiny OOP code. And here you can see that these two terms are same in fact: immutable service is a stateless service and vice versa.
However, it's awkward for me to call a value object "stateless object". It sounds terrible.
Recap: in case of services (network or OOP, doesn't matter) I'd say these terms are interchangeable.
Just example:
interface Logger
{
public function logWarning(string $message);
public function logError(string $message);
}
It doesn't matter how many times we called logWarning or logError and order of calls doesn't matter too. Thus, we can call it "stateless service".
But this service is also has no setters and any mutators like changeFileName() -> it is an immutable service/object.
Mutability makes object stateful.
Stateful makes object mutable.
These terms are interdependent in context of services.
They are definitely not the same.
Immutable objects are the never changed. The state of immutable objects is never modified, aliasing immutable objects is harmless and no alias control is necessary for immutable objects, although alias control may be needed to prove that objects are in fact immutable.
And stateless means there is no state.
HTTP is called a stateless protocol because each command is executed independently, without any knowledge of the commands that came before it. It is based on a request paradigm. In this protocol the communication generally takes place over a TCP/IP protocol.
Related
Reading documents of LightStreamer, some questions has remained which i cannot find them by reading docs.
What is the concept of snapshot?
What is difference between isActive() and isSubscribed() methods?
If anyone is familiar with these in websocket programming, please guide me.
In Lightstreamer terms, you subscribe to "items", each of which models an entity characterized by a state and a flow of updates of that state.
When you subscribe to an item, you may want to know the current state immediately; and then all subsequent updates, as soon as they occur.
To simplify the interface, the state is sent to the client in the same format of the updates; so it is made by zero or more special updates.
These special updates that carry the current state of the item are referred to as the snapshot.
The above is in abstract terms. The state of an entity can be made in many possible ways.
For this reason Lightstreamer introduces several types of items (i.e. MERGE, DISTINCT and COMMAND), which cover basic types of state.
They are described in detail by paragraph 3.2 of the General Concepts document.
2)
This distinction is introduced in client libraries, because these libraries represent each subscription with a Subscription object.
This object specifies the characteristics of a subscription request (of one or multiple items), but this request, in order to be fulfilled, needs two steps:
1 the application submits the request to the client library;
2 the client library submits the request to Lightstreamer Server.
Hence, after 1, the object's isActive() returns true, whereas, after 2, the object's isSubscribed() also returns true.
Note that the subscription request may have a complex lifecycle.
For instance, if the connection to the Server gets lost, the client library reconnects and reissues the subscription; in the meantime, isActive() is true and isSubscribed() is false.
Moreover, the application can later unsubscribe, but subsequently reuse the same Subscription object to request the same subscription again; in the meantime, isActive() is false (and isSubscribed() is obviously false).
I'm building a web application with Spring, and I'm at the point where I have an Entity, a Repository, a RestController, and I can access endpoints in my browser.
I'm now trying to return JSON data to the browser, and I'm seeing all of this stuff about DTOs in various guides.
Do I really need a DTO? Can't I just put the serialization logic on the entity itself?
I think, this is a little bit debatable question, where the short answer would be:
It depends.
Little longer answer
There are plenty of people, who, in plenty of cases, would prefer one approach (using DTOs) over another (using bare entities), and vice versa; however, there is no the single source of truth on which is better to use.
It very much depends on the requirements, architectural approach you decide to stick with, (even on) personal preference and other (project-related) specific details.
Some even claim that DTO is an anti-pattern; some love using them; some think, that data refinement/adjustment should happen on the consumer/client side (for various reasons, out of which, one can be No Policy for API changes).
That being said, YES, you can simply return the #Entity instance (or list of entities) right from your controller and there is no problem with this approach. I would even say, that this does not necessarily violate something from SOLID or Clean Code principles.again, it depends on what do you use a response for, what representation of data do you need, what should be the capacity and purpose of the object in question, and etc..
DTO is generally a good practice in the following scenarios:
When you want to aggregate the data for your object from different resources, i.e. you want to put some object transformation logic between the Persistence Layer and the Business(or Web) Layer:
Imagine you fetch from your database a List<Employee>; however, from another 3rd party web-service, you also receive some complementary-to-employee data for each Employee object, which you have to aggregate in the Employee objects (aggregate, or do some calculation, or etc. point is that you want to combine the data from different resources). This is a good case when you might want to use DTO pattern. It is reusable, it conforms to Single-Responsibility Principle, and it is well segregated from other layers;
When you don't necessarily combine data received from different sources, but you want to modify the entity which you will be returning:
Imagine you have a very big Entity (with a lot of fields), and the client, which calls the corresponding endpoint (Front-End application, Mobile, or any client), has no need of receiving this huge entity (or list of entities). If you, despite the client's requirement, will still be sending the original/unchanged entity, you will end up consuming network bandwidth/load inefficiently (more than enough), performance will be weaker, and generally, you will be just wasting computing resources for no good reason. In this case, you might want to transform your original Entity to the DTO object, which the client needs (only with required fields). Here, you might even want to implement different DTO classes, for one entity, for different consumers/clients.
However, if you are sure, that your table/relation representations (instances of #Entity classes) are exactly what the client needs, I see no necessity of introducing DTOs.
Supporting further the idea, that #Entity can be returned to the presentation layer without DTO
Java Persistence with Hibernate, Second Edition, in §3.3.2, even motivates it explicitly, that:
You can reuse persistent classes outside the context of persistence, in unit tests or in the presentation layer, for example. You can create instances in any runtime environment with the regular Java new operator, preserving testability and reusability;
Hibernate entities do not need to be explicitly Serializable;
You might also want to have a look at this question.
In general, it’s up to you to decide. If your application is relatively simple and you don’t expose any sensitive information, an response is y ambiguous for the client, there is nothing criminal in returning back the whole entity. If your client expect a small slice of entity, eg only 2-3 fields from 30 fields entity, then it make sense to do the translation or consider different protocol such as GraphQL.
It is ideal design where you should not expose the entity.
It is a good design to convert your entity to DTO before you pass the same to web layer.
These days RestJpacontrollers are also available.
But again it all varies from application to application which one to use.
If your application does a need only read only operation then make sense to use RestJpacontrollers and can use entity at web layer.
In other case where application modifies data frequently then in that case better option to opt DTO and use it at the UI layer.
Another case is of multiple requests are required to bring data for a particular task. In the same case data to be brought can be combined in a DTO so that only one request can bring all the required data.
We can use data of multiple entities data into one DTO.
This DTO can be used for the front end or in the rest API.
Do I really need a DTO? Can't I just put the serialization logic on the entity itself?
I'd say you don't, but it is better to use them, according to SOLID principles, namely single responsibility one. Entities are ORM should be used to interact with database, not being serialized and passed to the other layers.
Let's say I've got a domain class, which has functions, that are to be called in a sequence. Each function does its job but if the previous step in the sequence is not done yet, it throws an error. The other way is that each function completes the step required for it to run, and then executes its own logic. I feel that this way is not a good practice, since I am adding multiple responsibilities, and the caller wont know what all operations can happen when he invokes a method.
My question is, how to handle dependent scenarios in DDD. Is it the responsibility of the caller to invoke the methods in the right sequence? Or do we make the methods handle the dependent operations before it's own logic?
Is it the responsibility of the caller to invoke the methods in the right sequence?
It's ok if those methods have a business meaning. For example the client may book a flight, and then book a hotel room. Both of those is something the client understands, and it is the client's logic to call them in this sequence. On the other hand, inserting the reservation into the database, then committing (or whatever) is technical. The client should not have to deal with that at all. Or "initializing" an object, then calling other methods, then calling "close".
Requiring a sequence of technical calls is a form of temporal coupling, it is considered a bad practice, and is not directly related to DDD.
The solution is to model the problem better. There is probably a higher level use-case the caller wants achieved with this call sequence. So instead of publishing the individual "steps" required, just support the higher use-case as a whole.
In general you should always design with the goal to get any sequence of valid calls to actually mean something (as far as the language allows).
Update: A possible model for the mentioned "File" domain:
public interface LocalFile {
RemoteFile upload();
}
public interface RemoteFile {
RemoteFile convert(...);
LocalFile download();
}
From my point of view, what you are describing is the orchestration of domain model operations. That's the job of the application layer, the layer upon domain model. You should have an application service that would call the domain model methods in the right sequence, and it also should take into account whether some step has left any task undone, and in such case, tell the next step to perform it.
TLDR; Scroll to the bottom for the answer, but the backstory will give some good context.
If the caller into your domain must know the order in which to call things, then you have missed an opportunity to encapsulate business logic in your domain, which is a symptom of an anemic domain.
#RobertBräutigam made a very good point:
Requiring a sequence of technical calls is a form of temporal coupling, it is considered a bad practice, and is not directly related to DDD.
This is true, but it is worse when you do it with your domain model because non-domain concerns get intermixed with domain concerns. Intent becomes lost in a sea of non business logic. If you can, you look for a higher-order aggregate that encapsulates the ordering. To borrow Robert's example, rather than booking a flight then a hotel room, and forcing that on the client, you could have a Vacation aggregate take both and validate it.
I know that sounds wrong in your case, and I suspect you're right. There's a clear dependency that can't happen all at once, so we can't be the end of the story. When you have a clear dependency with intermediate transactions that must occur before the "final" state, we have... orchestration (think sagas, distributed transactions, domain events and all that goodness).
What you describe with file operations spans across transactions. The manipulation (state change) of a domain is transactional at each point in a distributed transaction, but is not transactional overall. So when #choquero70 says
you are describing is the orchestration of domain model operations. That's the job of the application layer, the layer upon domain model.
that's also correct. Orchestration is key. Each step must manipulate the state of the domain once, and once only, and leave it in a valid state, but it OK for there to be multiple steps.
Each of those individual points along the timeline are valid moments in the state of your domain.
So, back to your model. If you expose a single interface with multiple possible calls to all steps, then you leave yourself open to things being called out of order. Make this impossible or at least improbable. Orchestration is not just about what to do, but what to prevent from happening. Create smaller interfaces/classes to avoid accidentally increasing the "surface area" of what could be misused accidentally.
In this way, you are guiding the caller on what to do next by feeding them valid intermediate states. But, and this is the important part, the burden on what to call in what order is not on the caller. Sure, the caller could know what to do, but why force it.
Your basic algorithm is the same: upload, transform, download.
Is it the responsibility of the caller to invoke the methods in the right sequence?
Not exactly. Is the responsibility of the caller to choose from legitimate choices given the state of your domain. It's "your" responsibility to present these choices via business methods on your correctly modeled moment/interval aggregate suitable for the caller to use.
Or do we make the methods handle the dependent operations before it's own logic?
If you've setup orchestration correctly, this won't be necessary. But it does make sense to validate anyway.
On a side note, each step of the orchestration you do should be very linear in nature. I tell my developers to be suspicious of an orchestration step that has an if statement in it. If there's an if it's likely better to be part of another orchestration step or encapsulated in business logic.
I'm currently porting a massive, ancient, Oracle Forms app over to JSF & I need to make decisions on the domain model.
I'm locked in to using the Spring JDBC templates(no ORM) and utilizing a DAO layer to deal with baffling legacy database schema, which must have been desined by 1st year co-ops. For the domain model I would really like to make things highly OO, for instance: presume there is a domain object Plan. The goal would be too OO-ify it be able to do PlanInstance.load(byId("12345")), PlanInstance.save(), .delete(), .create(), etc etc. But then the situation arises; because these domain objects contain references to stateful beans(like Repositories for instance), then they can't be Serialized. How does one overcome this?
Initially I started splitting things up like: PlanData(Statefull, SessionScoped) which is used by PlanManager(Stateless, Singleton). This way the common controller code is extracted and is prevented from being duplicated in each session scoped bean, and most importantly allows the session scoped beans to be serialized.
At this point I really need to structure it OO style to minimize complexity, but I just don't know how I can have an object in session scope when it has references to stateful objects(due to serialization errors).
The only possibility I can think of is makeing the stateful refs transient & devising some sort of mechanism to re-inject the dependancies when a bean is un-serialized. Can any one provide me with any insight into solutions to this dilemma? There must be some sort of pattern/practice that solves which I am probably just missing.
I would keep the state and management of that state separate (i.e. Plan vs PlanManager.) By using the data access pattern (PlanManager), you keep the door open to using ORM later, (say) should the db schema be reworked in future. Putting state and state management together in the same class (PlanInstance) goes against the OO principle of single responsibility.
The stateful session scoped beans are not themselves serialized (at least not to store in your persistent store - but you might serialize them to support session fail over). The controller and session beans maintain references to your data beans.
The stateful beans decide when to load, invoking logic, change state and save your data objects. They provide the context for your domain objects. In some designs (often cited as the Anemic Domain Model) the domain objects have no behaviour, and all the logic exists in stateless services. If I understand correctly, you want encapsulation of state and behaviour in your domain objects, and that the domain objects need to use stateful session beans to perform their work. Where possible, try to factor the functionality in the domain objects to not rely upon session state (will make testing simpler), or to push that functionality out into a service bean that is invoked with the appropriate session state. If you have no choice but to use references to stateful beans from your domain model behaviour, the stateful beans can provide the necessary state/repository references as parameters to method calls on your domain objects. That way, the domain objects are still stateless, but can implement domain logic using stateful beans.
All the while, consider the single responsibility of the domain object. At some point it may become clear that the domain logic can be split into layers (say, low-level and higher-level logic) which may make the need for stateful beans in the domain objects unnecessary.
I have a method that returns lot of data, should I use #TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) for this method. The method perform a JPA query an loads the full content of a table (about 1000 rows).
The client to this method - is that already in a transaction? When you use NotSupported the caller transaction will be suspended. If not I would say, just put Never as the transaction type. Never is better since callers know they are not supposed to call this method from inside a transaction. A more straight forward contract.
We always use Never for methods that do more processing so that developers are aware right off the bat not to call if they are involved in a transaction already. Hope it helps.
I would care to disagree as it seldom happens that user is not in a transaction in almost all the systems. The best approach is to use NOT SUPPORTED so that the transaction is suspended if the caller is in any transaction already. NEVER is troublesome unless you have a series of calls which are all in NO TRANSACTION scope. In short, NOT SUPPORTED is the type one should use.
As far as I know (at least this is the case with Hibernate), you cannot use JPA outside of a transaction as the entity manager's lifecycle is linked to the transaction's lifecycle. So the actual method that does the query must be transactional.
However, you can set it to TransactionAttributeType.REQUIRES_NEW; this would suspend any existing transaction, start a new one, and stop it when the method returns. That means all your entities would be detached by the time they reach the caller, which is what it sounds like you're trying to achieve.
In more complex systems, it pays to completely separate your data layer from your business layer and create a new set of object. Your method will then call the JPA query, then use the entities returned to populate objects from your business layer, and return those. That way the caller can never get their hands on the actual JPA entities and you are free to do in your data layer what you want, since now it's just an implementation detail. (Heck, you could change the database call to a remote API call and your caller wouldn't have to know.)