In Grails there is a plug-in compile ":dto:0.2.4" to transfer Domain objects to DTOs. When using that plug-in the DTOs are created as Java classes.
For an example if there is Domain Class like Person.groovy the DTO is created like PersonDTO.java
What is the intention of this kind of a behavior ? Any comment would be appreciated.
Peter Ledbrook answer your question in this blog post.
Despite that, DTOs still persist (pardon the pun). When you want to
serialise data over RPC, they’re often one of the few options
available to you. GWT-RPC is a case in point, and the reason for the
Grails DTO plugin. Gilead allows you to transparently serialise
Hibernate domain instances, but this only works if the domain class
can be loaded by the client. Since GORM domain classes are typically
Groovy, that’s not an option with GWT. Your typical Grails domain
class also includes a bunch of stuff that the client is hardly going
to be interested in, like the custom mappings.
So, basically it can be an lightweight version of your domain class, only with the data that your client needs.
Not the case of Grails, that have static methods to database query's, but if you have a DAO class, the DTO pattern can be used to ensure that your client will not be allowed to perform the methods that touch the database. This can be good to ensure inappropriate use of this objects in your presentation layer.
Related
We've started considering using BreezeSharp as we have a WebAPI ODATA Service that we'd like to re-use with a ASP.NET site (no javascript involved, just pure C#).
Unfortunately, we just noticed that, according to the documentation, all of our model entities should now inherit from Breeze.Sharp.BaseEntity. That's a no go for us as this would mean having a dependency on Breeze in our business model. We'd rather keep this dependency on the WebAPI service only.
Is there anyway we could avoid this ? Having proxy classes on the client-side for instance when they don't inherit from BaseEntity ?
Any thoughts on this ?
The Breeze.Sharp.BaseEntity requirement is purely on the client side, and the reason for it is to provide all of the persistence, navigation, key-fixup, change tracking and notification and other services that make the breeze client so easy to use.
There is an IEntity interface that Breeze.Sharp.BaseEntity implements and you are free to implement it instead of using the Breeze.Sharp.BaseEntity, however, this is a very nontrivial task. We are considering offering some guidance on this at a later date if our community generally finds it desirable.
We are also planning on releasing an AOP implementation of IEntity that can be injected directly on top of POCO model objects, but this is likely to require PostSharp and may also have issues running on some client platforms (Xamarin for Android/IOS). No timeframe for this until we get a sense of the demand.
The current implementation on the other hand is very respectful of your model objects, there is only a single 'EntityAspect' property added to your model along with several events.
We have tried the pure POCO approach in the past, on numerous other platforms and application libs and have found that the disadvantages outweigh the minimal cost of a base class, especially when considering that we wanted this library to run in any .NET client including Xamarin/Mono.
If I understand correctly, your only concern is that you don't want to refer to breeze# libraries in your server model. Apparently you have no issue with close coupling of your client and server entity classes in the sense that they have identical properties and perhaps shared methods as well. I'm not being judgmental; I'm merely trying to confirm your architectural decisions.
Have you considered partial classes?
You define the partial class w/o breeze in your server-side business model project and link to that class source in your client model project ... where you keep the companion partial class with the client-specific functionality. That client partial class file specifies the breeze# base class.
While you are at it, you can segregate server-only logic in partial class files that reside in your server project but not in your client project.
Such source file linking has become even easier with VS now that Microsoft is promoting it in their vision of "Universal apps".
I'd like to make my usage of open-dolphin in grails sever as easy as possible. So, I'm looking for way to handle CRUD actions on domain classes(on the server side) automaticaly. In demos from open-dolphin project I havent found any idea how to achieve this(if I missed something, please point me where I should study). Instances are pulled from server on request and until it would be pulled/updated again there is no way to recognize changes that happen on server(I've been investigating mainly crudDemo in open-dolphin project).
Since CRUD actions can come not only from user via web or remote client, but also as consequence of other actions, cascade deletes, from services etc.(changes made to the database via sql, are probably untreatable), I thing that handle actions in classes controllers is not enough.
I came up with idea of handling CRUD actions using GORM events, with those I can keep dolphin models persistent with database, check PMs before update or delete, and probably handle all changes on domain classes instances that grails is doing. But, I have to write very similar logic to each class, be sure I havent missed any event on any class(scaffolding may help) and there are probably other consequences that I do not realize now..
So my question is: Is there any documentation, pattern, plugin, open-source code, etc., where open-dolphin is implemented into grails that way, that it autamaticaly propagates CRUD actions on domain classes instances to its presentation models? Or anything that aims to achieve this, using scaffolding, observing instances lists and properties, or something else?
Maybe, I misunderstood concept of using open-dolphin with grails, if so, I appreciate any good advice.
Thanks a lot!
for some reason I haven't seen your question before.
You can happily use Grails domain classes and GORM with OpenDolphin on the server side. The "CrudDemo" in OpenDolphin does exactly that.
Here are the domain classes: https://github.com/canoo/open-dolphin/tree/master/dolphin-grails/grails-app/domain/dolphin/grails
Here are the actions: https://github.com/canoo/open-dolphin/tree/master/subprojects/demo-javafx/server/src/main/groovy/org/opendolphin/demo/crud
Note that when we do testing and client and server-side actions run in-memory, there is no grails support available. Therefore, the server-side actions use service interfaces with DTOs instead of Grails domain classes. The implementation as a Grails service then uses Grails domain classes and GORM.
enjoy
Dierk
I am looking to build a relatively complex Neo4J application, which I intend to split up in two separete projects, namely frontend and backend. The frontend will be HTML5 and is not relevant for this question, the backend will have a REST interface with Jersey, but it's the structure behind that REST interface that I have questions about.
Atm, this is how I envisioned it :
RESTimpl <-DATA-> Service <-DTO-> Repository <-NODE-> DAO <--> Neo4j Singleton
The general flow would be that the RESTimpl receives JSON and converts it to simple java objects like Strings, int, ... Those are then passed on to the service who creates a DTO with them. That DTO is passed on to the repository which performs all the DAO calls needed to write such a DTO to the database (one DTO may require several nodes and relations to be created). For DAO I was thinking of creating both a Core API and Cypher implementation, which has just very basic graph functions like creating a node, creating a relation, deleting a node, ... Methods which are useful for all repositories basically. The Neo4j singleton would then contain my GraphDatabaseService instance and some configuration stuff.
This is a relatively complex structure but I want the project to be very modular. Makes it easy to do Dependency Injection. (Everything will be written against an interface as well)
However, all the examples on the internet have a different implementation. They actually make their DTO's a wrapper around the Neo4J node or at least store the underlying node in the DTO. But it does allow for just a REST-Service-DAO structure.
But it doesn't allow me to change the repository implementations and put a different database behind the application.
What would be the "most correct way" to do what I want to do?
I use exactly what you've described above and I find that it works very well(one project in production, one almost there) and does not mix concerns. I don't use Spring Data but it is an option to consider.
I have defined my domain objects as standard POJO's- no Neo4j stuff in them at all. Their persistence is managed by DAO's- which contain mostly Cypher queries, and in some cases some core API work depending on complexity.
The GraphDatabase is a injected (I have two contexts- the EmbeddedGraph implementation is injected for production and the ImpermanentGraph for tests).
A REST service is exposed using Jersey which deals with domain objects and/or DTO's.
So Neo4j code is only seen in the persistence layer.
Got a couple of general convenience methods exposed to index/fetch by index etc.
I wouldn't go the wrap-Node way- tried it but found that it brings along its own set of problems and results in a somewhat smelly design. Looks like you're on the right track (to me at least)
Ok it seems my project setup could use some improvments.
I currently have:
1. ASP.NET MVC3 Web project
2. NHibernate project with Repositories/Mappings and some session code.
3. Entities (models used in nhibernate like User.cs)
4. Interfaces (like IUser, IRepository<IUser>, IUserRepository...)
5. Common (UserService, ..)
Now the issue is that I my nhibernate models now need to implement IUser, which I don't like, but I was forced to do this since my IRepository is generic, and I could use IRepository<User> since User is in another project, so I had to create an interface and do IRepository<IUser>
I will never need to have another implemention of User, so this is bugging me.
How can I fix this while keeping things seperate so I can swap out my ORM?
The IUser interface must be defined in the Entities layer if your entities implement it, not in the Interfaces layer. Also I would probably rename this generic Interfaces layer to Repositories or AbstractRepositories or something. Also I would rename the Common layer to Services if it contains services aggregating your repositories.
So the picture could be:
ASP.NET MVC3 Web project
NHibernate project with Repositories/Mappings and some session code.
Domain Entities (models used in nhibernate like User.cs and implementing domain interfaces like IUser)
Repositories (like IRepository<IUser>, IUserRepository...)
Services (UserService, ..)
I think you should approach this problem from Domain Driven Design perspective. Domain should be persistent-ignorant. Proper implementation of DDD repository is a key here. Repository interface is specific, business-focused, not generic. Repository implementation encapsulates all the data access technicalities (ORM). Please take a look a this answer and these 2 articles:
How to write a repository
DDD: The Generic Repository
Your entities should be concrete types, not interfaces. Although you may never need to swap your ORM (as Ladislav is saying in comments), you should design it as if you will need to swap it. This mindset will really help you achieve persistence ignorance.
hope this question is not all too stupid, I'm trying to get a hold of more advanced programming principles and was thus trying to get used to Dependency Injection using Ninject.
So, my model is split up into several different .dll-projects. One project defines the model specifications (Interfaces) and a couple of others implement these interfaces. All model projects need to use some sort of database system, so they all need access to yet another .dll which implements all my database logic. It is important that all of them can access the same instance of my database object, though, so if wouldn't suffice to just create one instance for each model.
I'm not quite sure how to achieve this using dependency injection, though. My first thought was to create a seperate DI-project and bind all interfaces to their respective implementation, so the DI-project needed references to all the other projects (model interfaces & implementations, database system etc.). Then again, the models would need access to the DI project since, for example, they'd need to request the database system from the DI System (Ninject). Of course this would create a circular reference (binding DI project to model and model to DI project), so it's not possible.
Long story short, I'd need a programming pattern that allows me to bind model interfaces to their implementations but that also allows the model implementations to request other dependencies from Ninject, e.g.
IModel1 -> Model1
IModel2 -> Model2 (different project)
IDatabase -> Database (different project)
Model1 -> request IDatabase -> get Database instance
Model2 -> request IDatabase -> get the same Database instance
Would be glad to get a couple of suggestions, at the moment I'm stuck and out of ideas ;)
Thanks!
the models would need access to the DI project since, for example,
they'd need to request the database system from the DI System
(Ninject)
When you use dependency injection, the model shouldn't need to access the DI framework, since it is the DI framework that injects dependencies. The model objects should not be asking the DI container. When the your objects are asking the container for dependencies it is not called Dependency Injection, but Service Locator. Service Locator is an anti-pattern.
My first thought was to create a seperate DI-project
When you have a single application (e.g. a web app), the usual thing to do is completely configure the DI container in the startup project, as close as possible to the application’s entry point. This entry point where all object graphs are composed is called the Composition Root.
All model projects need to use some sort of database system, so they
all need access to yet another .dll which implements all my database
logic
Try making POCO (plain old CLR objects) model/entity objects, or at least, ensure that those objects don't need to reference any other project, which makes your architecture (and testing) much easier.
Use Ninject with the Register Resolve Release pattern from within a Composition Root.
The client application would use Ninject to inject the actual database and model implementations.
The client application therefore needs to reference the database, idatabase, model and imodel projects.
The idatabase and database projects need to reference the model project, as the methods will return model objects or collections of model objects. Have a look at the repository pattern.
Your model doesn't need to reference any of your projects.