I have an the following scenario:
// several classes that implement different interfaces
class A implements X,Y {}
class B implements Y,Z {}
class C implements X,Z {}
// other classes that contain collections of one of the interfaces(different objects)
class G {
Collection<X> mayContainAC;
}
class H {
Collection<Y> mayContainAB;
}
class I {
Collection<Z> mayContainBC;
}
How would I go about persisting this using JPA?
From what I can see JPA doesn't support Collections of interfaces. Is the correct?
JDO does support it but I am having difficulties getting JDO to place nicely with my Wicket app.
Thanks, Tom
How would I go about persisting this using JPA?
Not supported.
From what I can see JPA doesn't support Collections of interfaces. Is the correct?
If the interface has a single persistent implementer, then you can define it using the targetEntity.
If the interface has multiple implementers, it's not supported by standard JPA.
JDO does support it
Yes JDO does support persistent interfaces and we've been using them since 2007 in all of our designs because, you know, using interfaces in Java programming is like object oriented modeling 1.0.1. If your ORM doesn't support them then your so called 'transparent persistence' solution is actually not very transparent.
This and some other short comings have meant we have steered clear of the most popular JPA implementation and ended up using an ORM something slightly less popular but much more powerful and highly productive when it comes to object oriented modeling. We use DataNucleus/JDO where persistent interfaces work perfectly. I can't imagine building OO models without this support.
I'm not sure what the inherent architectural limitation is with the most popular JPA implementation that it can't support persistent interfaces.
As well as implementing the JDO standard DataNucleus also implements the JPA standard. There is a chance that DataNucleus/JPA does support persistent interfaces but I've only ever used DataNucleus with JDO so I don't know for sure.
but I am having difficulties getting JDO to place nicely with my Wicket app.
We have a massive (400+ persistent classes) web application/cloud platform deployed using JDO with the (most excellent) Wicket java UI framework and have never had a problem. We have created a couple of JDO specific IModel implementations that work with Wicket's model binding architecture. Let us know if you want to use these and we can open source them.
Related
We use Symfony 4 + Doctrine + APIPlateform to deliver a HTTP API.
APIPlateform exposes Doctrine entities as API Rest resources (via annotation inside entity class), which (I found) no a good practice, since the business model (exposed by the API) should be the same than the Symfony Doctrine model.
As a result, it more looks like a basic CRUD than a real application.
Am I wrong about that or is it possible to create kind of Doctrine virtual entities in order to use tools like APIPlatform (or even Symfony form)?
It's true that API platform seems to be strongly opinionated towards very simple CRUD cases.
Symfony Form component however will accept any object as the data. We normally use objects like MyThingType (extended from AbstractType) and MyThingDTO (data transfer object) for separating the UI from the business model and persistence layer. Works just fine.
API Platform has kind of a support for DTO's but in my opinion it's not that usable for complex scenarios. For complex application with good separation of concerns and complex business model it would seem that using Symfony controllers/form directly or perhaps with FOS Rest would be more direct way to achieve it.
https://api-platform.com/docs/core/dto/
You can hide some of the internals of your Doctrine entity by serialization groups but it's still not the same as real separation.
I'm trying to refactor an existing project into PureMVC. This is an Adobe AIR desktop app taking advantage of the SQLite library included with AIR and building upon it with a few other libraries:
Paul Robertson's excellent async SQLRunner
promise-as3 implementation of asynchronous promises
websql-js documentation for good measure
I made my current implementation of the database similar to websql-js's promise based SQL access layer and it works pretty well, however I am struggling to see how it can work in PureMVC.
Currently, I have my VOs that will be paired with DAOs (data access objects) for database access. Where I'm stuck is how to track the dbFile and sqlRunner instances across the entire program. The DAOs will need to know about the sqlRunner, or at the very least, the dbFile. Should the sqlRunner be treated as singleton-esque? Or created for every database query?
Finally, how do I expose the dbFile or sqlRunner to the DAOs? In my head right now I see keeping these in a DatabaseProxy that would be exposed to other proxies, and instantiate DAOs when needed. What about a DAO factory pattern?
I'm very new to PureMVC but I really like the structure and separation of roles. Please don't hesitate to tell me if this implementation simply will not work.
Typically in PureMVC you would use a Proxy to fetch remote data and populate the VOs used by your View, so in that respect your proposed architecture sounds fine.
DAOs are not a pattern I've ever seen used in conjunction with PureMVC (which is not to say that nobody does or should). However, if I was setting out to write a crud application in PureMVC, I would probably think in terms of a Proxy (or proxies) to read information from the database, and Commands to write it back.
I want to inject some aspects in to methods/properties regardless whether it is private, public or protected.
I have gone through many blogs and forums and couldn't find a helpful article on this.
Can any one guide me on this ?
There are limitations on how Unity intercept certain methods. Certainly it is a value-added feature on top of standard DI facilities provided by the framework. As far as I know, non of the Unity versions do not support AOP style interception on private methods, and constructors. TransparentProxyInterceptor would only intercept only the type's implemented interfaces or the type used by MarshalByRefObject And the VirtualMethodInterceptor would only intecept on virtual methods.
I don't think any new interceptors have been added to the Interception in v3.
Also note that usual private/protected even internal methods require special intervention for AOP style interception. This is more less out of bound for Unity because it requires IL re-writing which usually handled by dedicated AOP framworks such as PostSharp.
The Java EE 7 Tutorial says that no-interface view will "exposes a local" and "Business Interfaces" will "implement local business interfaces", but the code is same. What is the difference between them? Please give me an example, I am newbie.
In case that bean is implementing a local interface, the interface can be packaged in different module and this module can be later imported into the client application, thus hiding the implementation. On the other hand, no-interface view means that client would need to have dependency on the implementation which is less flexible solution.
So generally, you can safely use no-interface view when bean will interact only within your service (let's say some DAO helper class) and use bean with local interfaces it there is ever going to be used on the client side.
Nice explanation about all views is here.
The question(as stated in the title) comes to me as recently i was looking at Spring MVC 3.1 with annotation support and also considering DDD for an upcoming project. In the new Spring any POJO with its business methods can be annotated to act as controller, all the concerns that i would have addressed within a Controller class can be expressed exclusively through the annotations.
So, technically i can take any class and wire it to act as controller , the java code is free from any controller specific code, hence the java code could deal with things like checking security , starting txn etc. So will such a class belong to Presentation or Application layer ??
Taking that argument even further , we can pull out things like security, txn mgmt and express them through annotations , thus the java code is now that of the domain object. Will that mean we have fused together the 2 layers? Please clarify
You can't take any POJO and make it a controller. The controller's job is get inputs from the browser, call services, prepare the model for the view, and return the view to dispatch to. It's still a controller. Instead of configuring it through XML and method overrides, you configure it through annotations, that's all.
The code is very far from being free from any controller specific code. It still uses ModelAndView, BindingResult, etc.
I'll approach the question's title, regarding AOP:
AOP does not violate "layered architecture", specifically because by definition it is adding application-wide functionality regardless of the layer the functionality is being used in. The canonical AOP example is logging: not a layer, but a functionality--all layers do logging.
To sort-of tie in AOP to your question, consider transaction management, which may be handled via Spring's AOP mechanism. "Transactions" themselves are not specific to any layer, although any given app may only require transactions in only a single layer. In that case, AOP doesn't violate layered architecture because it's only being applied to a single layer.
In an application where transactions may cross layers IMO it still doesn't violate any layering principles, because where the transactions live isn't really relevant: all that matters is that "this chunk of functionality must be transactional". Even if that transaction spans several app boundaries.
In fact, I'd say that using AOP in such a case specifically preserves layers, because the TX code isn't mechanically reproduced across all those layers, and no single layer needs to wonder (a) if it's being called in a transactional context, or (b) which transactional context it's in.