Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have gone through this link but i'm looking for convincing answer.
Visit http://www.coderanch.com/t/270170/java-programmer-SCJP/certification/Difference-serialization-persistence
Serialization is the process of converting an object to another representation (often binary, though you can serialize to other forms like xml, but the default java serialization mechanism is to a binary form). You can persist that serialized form of the object for reading in (deserialization) to restore that object. Serialization is also used as a mechanism for sending java objects across processes/machines (e.g. with RMI). Serialization is not persistence but persistence is one way it can be used.
Simple answer: Serialization is the process of changing the represenation of an object to another (mainly for the purpose of transfering it over a communication mechanism), whilst persistence targets the purpose of persisting (yes, it is the same word) object states ( for later retrievment) to a physical storage.
Both topics are strongly related, though. Most persistence layers rely on object serialization and deserialization and not too many provide binary dump and restoring of objects.
Interestingly most developers see implementing processes of de/serialization as a rather boring task whilst developing a persistence layer is more part of interest.
Well, obviously, the second one is more complex and the former one is often just a subtask of it.
Persistence - a mechanism to allow you to keep status between executions of your application.
Perhaps a database, maybe files, sometimes cache, in some cases very weird like in the cloud.
Serialization - a way of representing an object in a serial form that allows it to be stored for later recovery.
Often used to persist objects.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a monolithic app that does the following logics:
Get a list A (Customer) from database
Validate data in A using some criteria, if it's not validated, throw an error
Do some operations on A to get a list B (e.g. Regional customers)
Do sth with B
Now I am transforming my app using microservices, but I have trouble in designing the calls.
As B can be deduced from A entirely, I want to just make a single micro service getCustomerA that returns all the dataset A. That means a single database access is needed. That will be a performance plus.
But the problem is, the operations on A to retrieve list B is also part of the business code. So it's more logical to put these codes in Customer microservice side, if we follow domain driven design, in microservice Customer, maybe getRegionalCustomer.
So I want to know, what is the best practice in this case ? Should we priotize the single database call (first case) or it's better to do two calls (but in this case, 2 database calls) ?
Since this is mainly opinion based I can only give you that :-)
From my experience splitting the app into microservices just for the sake of doing it puts technical dogma over technical simplicity and often introduces a lot of unnecessary overhead.
With regard to the database calls I can also tell you from experience that quite often you win performance when doing two simple calls over doing one overly complex one. Especially if you start introducing big joins over many tables or - ouch - subselects in the on clause.
See if the most simple solution works and keeps the code tidy. Constantly improve quality and optimize when the need for it arises. If you have a piece of logic that warrants to be split of into a microservice (e.g. because you want to use a different language, framework or want to offload some calculations) then go for it.
Domain driven design does not tell that each boundle context only can contains one entity, in fact, a bounded context (or microservice) can contains more than one entity when these entites are clearly related, in other words, when they need to be persisted transactionally.
In your case, due to the tight relation between the two entites, the best way is to build only one microservice that do both operations
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have three micro services MSA, MSB and MSC. The micro service MSA creates a partial object O1 and sends to MSB only through a dedicated message topic. After receiving the partial object O1 from MSA, MSB populates few more attributes in O1 and shares in the common message bus from which MSC consumes the object O1.
Question is that, is this a good approach where the object building is shared across multiple micro services?
Here it's your response:
In object-oriented programming, a God object is an object that knows too much or does too much. The God object is an example of an anti-pattern.
A common programming technique is to separate a large problem into several smaller problems (a divide and conquer strategy) and create solutions for each of them. Once the smaller problems are solved, the big problem as a whole has been solved. Therefore a given object for a small problem need only know about itself. Likewise, there is only one set of problems an object needs to solve: its own problems.
So you have a microservice Ordering and a microservice Pricing. Both of the microservices need information about the Product entity.
You should ask yourself:
Do those two different worlds realize the Product entity in the same way? Both of them need the same information?
Will the product information change for the same reasons for both of the microservices?
If no (which is likely the case), you have to add an abstract layer between them, so that you are sure that they use the same language.
If yes, you can keep on sharing the same object.
By the way, these concerns that you have is not a new thing.
Here is Martin Fowler's article about bounded contexts
So instead DDD divides up a large system into Bounded Contexts, each
of which can have a unified model - essentially a way of structuring
MultipleCanonicalModels.
keywords for further research: DDD, context map, bounded context, anticorruption layer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I need to persist objects and I want to keep my data classes as clean as possible. The persisted classes do not feature any business-logic code, but only data with getters/setters.
I'm currently implementing a solution with the Observer pattern. Each time an Observable persisted object is modified, it fires a message to an Observer object that takes care of persistence. This way, the only constraint for the persisted object is to be "Observable". It keeps things clean.
Another solution (maybe better?) would be to implement some DAO pattern, and I'm not very aware of the way it works. Maybe it would look like persistedObject.save(); or persistedObject.readById(id);. But it means I would have to define some DAO interface and then to implement the read/create/update/delete method in each and every persisted class
There are many, many, many answers to this question, data serialization or persistence is a core problem in software engineering. Options include using databases, memory mapped files, binary and textual formats, and more.
My personal favorite for quickly persisting objects is GSON, however your use case will dictate what works best for you.
You mention wanting design patterns for persisting Java objects, and while such patterns are approximately as numerous as there are libraries, here are a couple general suggestions:
Use immutable objects
Use the transient keyword for any fields that are not necessary to reconstruct an object
Avoid defining sanity checks or otherwise limiting the range of acceptable values in your objects - an instance constructed from a deserialize call may not correctly trigger your checks, allowing possibly invalid objects to be constructed
Use your serializable objects to construct more complex objects if you need more sanity checking, e.g. serialize a StubPerson POJO, and have a Person object that can be constructed from a StubPerson only as long as the stub's values are valid
I don't know if it fits for you but since you have only bean classes you could use the Java persistence api.
The DAO pattern is the best one to manage data access and persistence as it has been designed specifically for that.
Considering your needs you will probably have to couple it with some factory pattern in order to manage the different implementations (persistence adapters).
I don't know your requirements but if your application can be used by many persons at the same time you will have to care about concurrent accesses and define a policy (transaction, locking, etc... otherwise people will overwrite data each others).
Regarding your question i'd suggest JDO (with data nucleus as implementation) but the learning curve may be too expensive for your effective needs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
To design a project and draw a UML class diagram, what must the class diagram include?
Suppose our classes have textfields, buttons etc. Must they be included as members?
Suppose we need to perform some form validations, and we intend to perform it by passing data obtained from a form to a "validator" object, must it be also included in the class diagram?
I received some opinions from colleagues that a class diagram is for design phase and must not include objects like I mentioned above. However when the project completes, won't there be a large number of objects we did not draw in the class diagram?
UML is a language. The way you use it is up to you.
Ideally you will have multiple documents. The reason you will need multiple documents is because the most important tip of documentation writing is to restrict yourself to one perspective per document.
You want a static representation of objects -> don't talk about files
You want to show relations between objects -> don't talk about data flow.
You get the idea. As long as you are clear with what the purpose of the document is and consistent to the legend, UML can tell any story.
For your specific question:
Since you're creating a class diagram (a static representation of system objects), the important bits will likely be what goes into each object/class (not the input fields of the form itself, but the structure of the object those fields are eventually saved to), and how they relate to other objects.
You can include the validator object and connect it to the objects its validating, but modeling how it's validating, when it's validating, or the protocol with which they communicate is not relevant for this specific view.
Generally in UML diagrams, you exclude extraneous data. Depending on how in-depth you want to be, things such as a UI controls and getter/setter methods are usually excluded.
On the other hand, your Validator object should be defined as a control class in your UML diagram, as it has a responsibility and purpose within your system.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm developing an application in Java with MVC architecture. Doing so has greatly decoupled and simplified my code, but the problem is that the model has no intrinsic visual representation. That is, there are no characters, no specific enemies, no buttons, no text boxes - the model is made up of hundreds of instances of one type of object. Each instance is controlled by an instance of a strategy pattern (technically, it's a hierarchy of strategy patterns); it is the only differing point between each instance in the application. The type of strategy each instance uses should therefore ideally make it look slightly different than others around it.
I'd like to avoid a giant if statement chain with dozens of "instance of" calls checking for the type of strategy used when developing a view for this application. I'd also like to avoid a similar chain using an enumeration. Any suggestions as to how I can make my view without succumbing to a massive if chain? Any suggestions as to how I could design my view properly so that it wouldn't be so tightly coupled to the strategy instances?
Thanks in advance for your time!
#DJClayworth asks the critical question:
Are you interested in presenting to the user the strategy [to be] selected, or the results of that strategy?
Assuming you'll need both, let the model contain an enumeration relating strategy names, implementations and descriptive text. The implementation can use a class literal as a runtime-type token.
In this example, enum Rule serves all three purposes as an implicit model. It supplies a legible name and description, as well as a constant representing a particular composite strategy. No case statements are required.