In our system we often receive a number of user requests in one time. So we are creating prototype-beans and start proceeding the requests.
In these prototype-beans we use of course some other beans.
So my question: is it wise and possible to use singleton-beans in prototype-beans? If yes, what are the conditions for proper usage?
I would think that if I make only one singleton-service to be used by a number of prototype-beans it is effective.
However what would happen when several beans will ask for one singleton-bean in one time?
Is it wise and possible to use singleton-beans in prototype-beans?
It strongly depends on what your beans look like. If you store data in a singleton bean's fields you will have to think about synchronization. If your beans are totally stateless (by using a database as persistence for example), you don't need to worry about using a single instance of a bean all over the place.
However the other way around (using prototype beans in singletons) may be very risky. As there is only one instance of the singleton in the JVM, this singleton will hold a reference to the very same prototype instance for each caller. Making it statefull and subject to synchronization issues.
What would happen when several beans will ask for one singleton-bean in one time?
An instantiated Java class is very much only a collection of data and instructions somewhere in the memory, a variable to this class holds the reference where to lookup the stuff. If a class' functions are to be executed the processor looks up the things in the memory. If there is more than one reference to the same class, this means that the same memory address is referenced multiple times. The JVM manages memory access and guarantees compliance to the Java Memory Model. This is something you should be aware of, but is usually not that important for your day-to-day business - unless you implement the JVM of course :-)
I'm seeing a NotSerializableException in the logs for a few of our model objects and I know that the fix for this is to make them serializable, but we are also seeing MarkupExceptions about components not being added to the page and I'm wondering if this could be related. We're only seeing the errors in production where clustering is turned on.
So my question is, what happens when a model object is not serializable, even if all it's attributes are serializable?
As far as I know, if you do not declare a class as serializable, then it will be missing from the serialized version on the subsequent actions (e.g. form submissions, behaviour, AJAX). Consequently, when the object is deserialized, it is likely that any object references will be null if child object cannot successfully be reloaded from the storage.
You should definitely avoid serializing objects unnecessarily. This includes in response to AJAX requests.
Best practices dictate:
Store only the minimum serialized objects required
Avoid declaring variables 'final' and referencing these from anonymous inner classes
Avoid having too many objects stored as fields in serialized objects (pages, panels or lists, etc)
Load objects for each request - especially model objects, which should be loaded from your data repository as each request is processed
Load your data objects outside of the constructor
Use models for all data, and attempt to mirror the Wicket structure for simplicity (e.g. using CompoundPropertyModel, where fields are loaded from the model object using reflection, based on the wicket:id used)
Use detachable models for any large objects that are loaded
Avoid using anonymous inner classes too much - use proper event handlers so your code is easier to read and maintain.
I have been working on a complex Wicket application for some time and I can tell you that you want to avoid duplicate objects appearing due to overuse of serialization / deserialization - it can be a nightmare to debug and fix.
Have a read of these for more information / suggestions:
http://letsgetdugg.com/2009/04/19/wicket-anti-patterns-avoiding-session-bloat/
https://cwiki.apache.org/confluence/display/WICKET/Best+Practices+and+Gotchas
I want to change a flag on a series of objects. What is the standard DAO practise for:
Changing a property of all objects represented in a table?
Merging a list of objects?
You stumbled upon one of the things where the classical DAO approach can often lead to bad performance. Depending on your persistence engine, it will be extremely tricky to turn this into ONE efficient UPDATE statement instead of having to update hundreds of objects individually.
I would look at my business objects, estimate the amount of objects one can change at the same time and measure the impact on having a 'pure' oo domain model (which usually boils down to iterating through those objects and changing them one at a time) or adding a custom method that will do a batch update call for just this situation.
As I understand, Data Transfer Objects are used for different purposes, so let's bound the scope with the view layer in Java (JSF) -based web-applications (i.e. there are usually some entity-objects mapped on a DB, which can be also used in a Business-Logic layer, and some transfer objects used in a presentation layer).
So, I have some misunderstanding about how should well-designed DTOs look. Should I keep them as small as possible? Or should I try to pass with them as much information as possible and design them in such way that only some (different in different use-cases) part of the DTO fields is initialized at a time?
Should I consider using some OO principles (at least inheritance and composition) when designing DTOs or they should be as simple as only a number of primitive-type fields with their accessors?
DTOs, if at all different from the domain objects/entities, should be as big as needed - you should transfer exactly all data that you need.
DTOs in any language should be pretty light weight. Whether or not to use inheritance is a question only you could answer - it really depends on the business needs. Otherwise the DTO itself should include the basic get/set properties.
Generally these objects are pretty light weight, however it really depends on the data / properties you need. If your DTO has 1 property vs 50 properties, if you need 50 so be it. When it comes time to passing data to functions / methods the DTO saves your life from having to add all those extra parameters. You're essentially just passing one object.
DTOs should be as lightweight as possible, distinct from the business objects, and limited in scope (for example package level objects).
I say they should be separate from the business objects, contrary to Bozho's statement "if at all different from the domain objects", because a DTO will often need setters that users of the business object should not use.
I have, for example, a Person object and a PersonDTO... the DTO needs a setter for the person's name (first, last, etc.) but that is retrieved from an external data source and my application is not allowed to change it, so my business object "Person" shouldn't have a setter.
I've recently overheard people saying that data transfer objects (DTOs) are an anti-pattern.
Why? What are the alternatives?
Some projects have all data twice. Once as domain objects, and once as data transfer objects.
This duplication has a huge cost, so the architecture needs to get a huge benefit from this separation to be worth it.
DTOs are not an anti-pattern. When you're sending some data across the wire (say, to an web page in an Ajax call), you want to be sure that you conserve bandwidth by only sending data that the destination will use. Also, often it is convenient for the presentation layer to have the data in a slightly different format than a native business object.
I know this is a Java-oriented question, but in .NET languages anonymous types, serialization, and LINQ allow DTOs to be constructed on-the-fly, which reduces the setup and overhead of using them.
"DTO an AntiPattern in EJB 3.0" (original link currently offline) says:
The heavy weight nature of Entity
Beans in EJB specifications prior to
EJB 3.0, resulted in the usage of
design patterns like Data Transfer
Objects (DTO). DTOs became the
lightweight objects (which should have
been the entity beans themselves in
the first place), used for sending the
data across the tiers... now EJB 3.0
spec makes the Entity bean model same
as Plain old Java object (POJO). With
this new POJO model, you will no
longer need to create a DTO for each
entity or for a set of entities... If
you want to send the EJB 3.0 entities
across the tier make them just
implement java.io.Serialiazable
OO purists would say that DTO is anti-pattern because objects become data table representations instead of real domain objects.
I don't think DTOs are an anti-pattern per se, but there are antipatterns associated with the use of DTOs. Bill Dudney refers to DTO explosion as an example:
http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf
There are also a number of abuses of DTOs mentioned here:
http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/
They originated because of three tier systems (typically using EJB as technology) as a means to pass data between tiers. Most modern day Java systems based on frameworks such as Spring take a alternative simplified view using POJOs as domain objects (often annotated with JPA etc...) in a single tier... The use of DTOs here is unnecessary.
Some consider DTOs an anti-pattern due to their possible abuses. They're often used when they shouldn't be/don't need to be.
This article vaguely describes some abuses.
The question should not be "why", but "when".
Definitively it's anti-pattern when only result of using it is higher cost - run-time or maintenance. I worked on projects having hundreds of DTOs identical to database entity classes. Each time you wanted to add a single field you ad to add id like four times - to DTO, to entity, to conversion from DTO to domain classes or entities, the inverse conversion, ... You forgot some of the places and data got inconsistent.
It's not anti-pattern when you really need different representation of domain classes - flatter, richer, ...
Personally I start with a domain class and pass it around, with proper checks at the right places. I can annotate and/or add some "helper" classes to make mappings to database, to serialization formats like JSON or XML ... I can always split a class to two if I feel the need.
It's about your point of view - I prefer to look at a domain object as a single object playing various roles, instead of multiple objects created from each other. If the only role an object is to transport data, then it's DTO.
If you're building a distributed system, then DTOs are certainly not an anti pattern. Not everyone will develop in that sense, but if you have a (for example) Open Social app all running off JavaScript.
It will post a load of data to your API. This is then deserialized into some form of object, typically a DTO/Request object. This can then be validated to ensure the data entered is correct before being converted into a model object.
In my opinion, it's seen as an anti-pattern because it's mis-used. If you're not build a distributed system, chances are you don't need them.
DTO becomes a necessity and not an ANTI-PATTERN when you have all your domain objects load associated objects EAGERly.
If you don't make DTOs, you will have unnecessary transferred objects from your business layer to your client/web layer.
To limit overhead for this case, rather transfer DTOs.
I think the people mean it could be an anti-pattern if you implement all remote objects as DTOs. A DTO is merely just a set of attributes and if you have big objects you would always transfer all the attributes even if you do not need or use them. In the latter case prefer using a Proxy pattern.
The intention of a Data Transfer Object is to store data from different sources and then transfer it into a database (or Remote Facade) at once.
However, the DTO pattern violates the Single Responsibility Principle, since the DTO not only stores data, but also transfers it from or to the database/facade.
The need to separate data objects from business objects is not an antipattern, since it is probably required to separate the database layer anyway.
Instead of DTOs you should use the Aggregate and Repository Patterns, which separates the collection of objects (Aggregate) and the data transfer (Repository).
To transfer a group of objects you can use the Unit Of Work pattern, that holds a set of Repositories and a transaction context; in order to transfer each object in the aggregate separately within the transaction.