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 found this post earlier today about whether to XSD --> POJO or POJO --> to XSD.
Java to XSD or XSD to Java
It made us question whether we should even bother with making XSDs in our scenario. We assumed we should write XSD then generate Java POJOs from it, and then use those POJOs to transfer data between our REST server and clients. But what value do those XSDs have if we could just directly write the POJOs with the required annotations?
We thought it might help to write a custom XSD GUI tool instead of hand coding the XSD and that could be one benefit of having XSD. But I assume there are also GUI tools for creating JAXB beans?
Is it worth having XSD at the cost of the extra project complexity of having them and needing to generate the classes before compile time in our scenario?
One benefit of an XML Scheme over a set of JAXB-annotated classes would be that you have a definition for "foreign" communication partners. Maybe you don't need it now, but what about tomorrow?
Another good reason of using XML Schema is that (if used wisely) restricts your types to what is easily (un)marshalled. It's possible to create POJO classes that are darned hard to serialize.
The third reason iÍ can think of is that you don't have to learn how to cope with all of those javax.xml.annotation annotation classes. It may be that you feel more familiar with them (and they may even permit you to do a trick or two over the XML Schema approach) but I've usually found it more convenient to write an XML Schema and watch xjc to handle the nitty-gritty details for me.
It depends on your requirements. In some cases the requirements (of request/response maybe) are defined by the means of a XSD document as xsd can provide all the information(datatype etc) we need to build the classes, in these cases direct generation of POJO is helpful as we already have an xsd in place.
It might be a overhead for your case, if you have to first write an xsd and then generate an POJO object from it.
See what suits you, Choose wisely!
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
We are building Microservices using spring boot, however we have part of our project will be responsible for connecting with ESB through MQ and our contract is XSDs.
Our design team have 3 options:
Go for generation with JAXB "Generating POGO, building the marshaling and unmarshaling, and generating XML request and Response"
Using Staxs as a XML parsing library "However we didn't have any stream of data to be parsed"
Handcrafted Parser
Design team rejects JAXB as a solution for this concerns:
Custom validation cannot be handled in JAXB with spring boot
JAXB marshaling and unmarshaling will cause performance issue
ESB returned response will not comply with UI "however our services is stateless and ESB responses must not serve UI or being tightly coupled"
So Please i need to know what is the best approach that we can follow, Dev team see's the handcrafted approach is very time consuming.
and accuracy of written model and classes will no be the most accurate for that case.
Thanks,
Hamed
Is there any evidence from the design team for these claims?
You can patch many custom validations on top of jaxb. There might be some frameworks that don't work well together with jaxb, but a general "cannot be handled" requires some evidence or specifics.
Depends on the actual requests. Ask to see performed benchmarks.
I dont really see how the approach to xml parsing would change that.
Anyway, there are a lot of xml parsing options. Without specifics/requirements it is hard to specifiy "the best" for that case. The actual requirements are usually so low and all common libraries are so good, that it doesnt really matter.
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 4 years ago.
Improve this question
I need some guidance in designing an API wrapper for my backend APIs. I have tried to keep it as specific as possible.
Context: We have a project which supports certain file operations like edit, create, merge etc. All the services are exposed as rest APIs. Now I have to create an API wrapper over this (client library) in Java. I've been reading about DDD and trying to approach the problem using that.
As per my thinking, the core object in my project would be File, along with some minor DTOs for talking to the backend. Edit, create, merge will be the verbs here acting on my domain object. I want to make it as easy as possible for the external developer to integrate the API. I would like the design to be something like that
For Creating a file : File.create() For editing : File.edit() Same for other operations Also, I want to have the capability of chaining operations (along the lines of fluent interfaces) for readability
For. eg. if you want to create a file and then convert it, it should be something like : File.create().convert(Required params)
My problem is each of the operation is bulky and async. I don't wanna write all the async error handling logic in the File class. Chaining the methods like above wont be easy as well if they return CompletableFuture objects, and this will be harder to maintain.
Question: What is a better way of solving this problem?
I am not looking for a spoonfed design. I just want to be guided to a design approach which fits the scenario. Feel free to point if I am understanding DDD wrong.
Very roughly: your domain model is responsible for bookkeeping. The effects on the state of the filesystem are implemented in your infrastructure layer, and you send the results back to the bookkeeper.
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 6 years ago.
Improve this question
Hi I'm setting up a new project and was struggeling with Java Annotations.
Are they related to Logic / API or Model
In Detail:
I have a started a multi maven module for example:
project-parent
project-model
project-persist
project-logic1
I separated model from every other module simple POJOs with JPA.
To use them with different frontends or REST etc.
Now I wanna use annotations from project-logic1 in the model.
Now i'm confused with the seperation.
Should I make an own API module (project-API) for this and similar annotation / interfaces
Should I simply add the annotation in the project-model
Should I add the dependency of project-logic1 into the project-model POM
I think the first one is correctly but I'm not sure.
From what I understand, you shouldn't use your model objects (with the JPA annotations) as DTO in your project.
You should have your model within the logic project, so DB related items are un the same place, and you create and API project with only POJO, not related to your DB, so you can use this API for REST services' answers and keep your implementation hidden.
If you have common code, I would suggest to wrap it into a dedicated module, so I would agree with your "API"-Approach (although the label "API" might be too much here).
Do not cross-reference your modules, dependencies must always go one way. And: Never repeat yourself, so c/p-ing your annotations is fundamentally wrong ;)
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 am basically interested in analyzing the object form that we need to send to client over network in client-server model.
i need to know what are the criteria that we need to consider when we choose xml and java serialization respectively. which is the best approach to choose for object transform over network.
why serialization came into picture when we have already XML,JSON transformation already
Edit :
I wanted to know the why serialization is being used when we have XML/JSON already being used before its invention
If XML and JSON works for you I would stick with that. It is much easier to log and check it is doing what you believe it should be.
Java Serialization has many advantages however unless you need these they are unlikely to be the best solution.
it is built in, no extra JAR is required.
it is integrated with existing remote APIs
it supports all serializable object types and graphs. (XML and JSON only support trees of data, not typed objects)
it supports data types and you only write each reference once.
However Java Serialization is not
very efficient
easy to read/validate as a human.
flexible for schema changes esp changes in package or class names.
portable outside Java.
Personally, my preference is YAML. This is because
it was designed to be human readable where as XML is a subset of SGML and JSON a sub-set of Javascript.
it supports graphs and data types.
it is almost as efficient as JSON (it's a bit slower as it does more)
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
For instance, when I know how all representations should look like, which path has more advantages.
Creating/Annotating Java classes and then document them in (lets say) XML documentations.
Write XML representation and then generate Java classes.
From what I may think of:
First approach would increase development speed. Since documentation is the last step (when it's feasible).
Second approach may let me feel as I am the client (for my own App) and will lead me to consider, how practical is my representation from a user standpoint.
But I have no other ideas, while I assume that this topic might be important in some cases, that I just don't know yet.
My answer is "it depends".
I've written quite a lot of REST services and I stick by very simple rules:
If this is a public facing API and by public I mean that you do not control all the clients consuming it, or once they're released they're in the wild then I will write the API first and make my Java model fit into that
If it's purely internal and you have the ability to change at will then go for the Java model first and just use whatever representation gets spit out.
The latter is the faster development model but it relies on you not really caring about what the actual representation looks like.
Java POJO's can easily be serialized to xml so I would generate the xml from existing java POJOS (although I agree with the commenter json is usually better)
I would go for POJOs like ghostbust555. The reason for that is XML is just one of many serialization formats. You could JSON or even your proprietary text format (or binary format).
If you take plain POJOs you can then annotate them for XML marshalling / unmarshalling via JAXB for instance. You could also use them for binary protocols such as Apache Thrift.
Lastly you could actually start from a UML class diagram and use that to generate your POJOs. That helps you document your model better.
creating POJOs is better then XML documents.