I've got a Person class that can be an invitee to multiple Events. An Event keeps track of people and also a list of phonenumbers, for people that don't have a record in Person. When a Person gets deleted, we want to move their phone number to the list of phonenumbers for events that that person was invited to.
I've considered using #PreRemove in Person, but Spring doesn't like injecting an event repository in the User entity. Nor is there a way to save the particular Person within #PreRmove and do a cascade persist.
I've also considered doing an event listener, but I get a circular dependency error when I inject either an event or person repository inside there to perform a save on the events.
Is there a way to do to this in Spring?
Thanks to Andrey for the suggestion. Following this article on #DomainEvents, I was able to get this working.
Related
I'm sure there is a simple solution to my problem but I'm having trouble finding it online so I would be very grateful if someone could point me in the right direction.
So I have a Spring Boot application that uses an external database. I have a table and class called Ingredient that contains the various ingredients. That class has all the necessary methods (PUT, POST, DELETE, GET) and they work as intended.
Now I need to implement another class called Food and every object of type Food should be initiated with a name and a list of Ingredients.
I don't know how to implement it. I made the class Food and I defined a #ManyToMany relationship between the two classes/tables but I don't know how to implement the POST method for the Food.
I tried googling but I'm having trouble wording my problem.
Is it possible to execute some C# code when checking the "Is Approved" checkbox for a Member?
Our site has a registration form which programmatically creates a user in the Members section, however the new Members must be approved by an admin and we would like to send an email to the Member when they are approved.
I think what you will need to do is look at MemberService.Saving and MemberService.Saved events and attach a custom event handler. See Determining if an entity is new for information on determining if you are dealing with a new or existing member. Below is copied from documentation:
In v6.2+ and 7.1+ you can use the extension method on any implementation of IEntity (which is nearly all models returned by the Umbraco Services):
var isNew = entity.IsNewEntity();
How it works
This is all possible because of the IRememberBeingDirty interface. Indeed the name of this interface is hilarious but it describes exactly what it does. All entities implement this interface which is extremely handy as it tracks not only the property data that has changed (because it inherits from yet another hilarious interface called ICanBeDirty) but also the property data that was changed before it was committed.
From here you should be able to check the property data you are interested in and send your email accordingly.
I have a simple 1:1 relationship:
class MyParentDomain{
String name
MyChildDomain onlyChild
}
class MyChildDomain{
String name
}
Now on a form where I want to make a new parent "Mom", there will be a list with all the existing children. Is there a current good-practice to add children on that same form? I'm imagining a "plus" button next to the drop-down list of "onlyChild" where I could see a form for new "MyChildDomain". I saw a link somewhere where people were talking about cracking this problem (will add the link as soon as I re-discover it). Has this been done? Is anyone doing something like this?
To my knowledge, this hasn't been generally applied to any templates or with a plugin (I might be wrong).
You can, however, use the "list" abilities that Grails has which allow you to submit a list of domain entity data and then build the list of child elements in the controller from the submitted data and persist that. I've never done this myself, however, so you will need to do a bit of digging on it.
As you may have guessed, attempting to create child entities on the fly via Ajax is likely not to work since the parent entity doesn't exist yet, so there's nothing to attach them to.
I'm trying to implement Domain Driven Design in my Symfony2 project and experience some problems.
After reading some articles on Domain Models I found, that
I should put all the business logic into my domain models(entities).
Application level stuff, that needs to be done and doesn't belong to domain logic is fired with Domain Events(sending emails, putting some messages to the queue, etc.)
Luckily, Symfony provides Events, but here is a problem - I can't raise event from my entity.
Symfony documentation suggects to use DI to inject the dispatcher into the class, that raises Event
http://symfony.com/doc/current/book/internals.html#passing-along-the-event-dispatcher-object
But Symfony Entities are newable, not injectable.
Right now I can see two ways:
1) Provide Event Dispather to Entity like this
class FooEntity
{
protected $dispatcher = null;
public function setEventDispatcher(EventDispatcher $dispatcher)
{
$this->dispatcher = $dispatcher;
}
}
2) Raise Events from the service(not from the Entity).
None of this options look pretty, because it seems to me that they break Domain Model ideology.
Can you point me in the right direction, please.
The idea of this here is to give paths to attain the DDD paradygm.
I do not want to shadow over #magnusnordlander answer, I will apply what he says.
Here is some of observations on the matter:
I think that the Entity itself should not have everything. It is sure not what the DDD people would say anyway. The [Doctrine2] Entity should only take care of the relationships (an entity with different variation too <= This is actually a thing that I was stuck for a while) and the aggregate root.
The Doctrine entity should only know about how to work with itself.
But, to Get Data or work with it, there is other stuff that you can use:
Repository
Is the thing that provides helpers to get your more sophisticated finders than what a quick findBy(array('id'=>$idvalue)) would do (and that the Entity/Assocation/Annotation cannot cover) and is indeed a great thing to have handy.
I personally tried to build all queries, and realized the EntityManager is already very good, out of the box. In most case, to my opinion: If you can /not/ use query or query builder, the better.
Business logic in all that...
Last thing on note, what you would be searching for must be to basically thin the Controller.
FooManager (for example) is where (if I am not mistaken) the business logic go.
I found a goldmine of information on that matter on this blog that covers:
Controllers and application logic revisited
Putting controllers in a diet, and mix it with some custom Event with
Leveraging the Symfony2 Event dispatcher
If you have any ideas, to augument, I set this answer as a Community Wiki
By Symfony entities, do you mean Doctrine 2 entities? If so, you can set services on both new objects and old objects that are loaded from the database in the following manner:
Prototype scoped service
Services in the prototype scope are always recreated when you get them. Instead of doing new FooEntity you would do $container->get('foo_entity').
In the YAML syntax you would define the service as follows:
foo_entity:
class: FooEntity
calls:
- [setEventDispatcher, [#event_dispatcher]]
scope: prototype
This will take care of new entities. For existing entities you need a...
Post load event listener
Create an event listener, in the manner described here:
http://symfony.com/doc/current/cookbook/doctrine/event_listeners_subscribers.html
Have the listener listen for the postLoad-event. Inject the event dispatcher into the listener service, and use the listener service to set the event dispatcher on the entity.
Bear in mind that the listener service will fire after loading any entity, not just the FooEntity, so you'll need to do a type check.
I've asked the question a few different times in a few different ways and I haven't yet gotten any responses. I'm trying again because I feel like my solution is too convoluted and I must be missing something simpler to do.
Using EF 4.1, POCO, DbContext API, AutoMapper, and Razor in an MVC 3 application.
I have a many-to-many relationship between two of my entities: Proposals and CategoryTags. I can successfully map (Automapper) a Proposal to my ProposalViewModel including the collection of CategoryTags.
In my View, I use javascript to allow the user to add, update, and remove tags by dynamically creating elements, each one that stores the ID of the chosen tag.
I can successfully post my ViewModel back to my controller with it's CategoryTags collection populated (although only with the ID property for each CategoryTag).
When that ViewModel is posted back to my controller, I don't know how to get those tags from the ViewModel and add them to my Model in such a way that db.SaveChanges() updates the database properly.
The only way I've had any success is to disconnect the CategoryTags collection in mapping (by namig them differently), iterate through each tag and manually look it up in my context and then call the .add() method. This is sloppy for a number of reasons which leads me to believe I'm doing it wrong.
Can anyone offer any direction at all?
UPDATE:
For anyone who is interested, my functional code:
Dim p As New Proposal
Dim tempTag As CategoryTag
p = AutoMapper.Mapper.Map(Of ProposalViewModel, Proposal)(pvm)
db.Proposals.Attach(p)
db.Entry(p).Collection("CategoryTags").Load()
For Each ct In pvm.Tags
tempTag = db.CategoryTags.Find(ct.Id)
If tempTag Is Nothing Then
Continue For
End If
If ct.Tag = "removeMe" Then
p.CategoryTags.Remove(tempTag)
Continue For
End If
p.CategoryTags.Add(tempTag)
Next
db.Entry(p).State = EntityState.Modified
db.SaveChanges()
Return RedirectToAction("Index")
The only working way is doing this manually - you can read full description of the problem if you want. The description is related to ObjectContext API but DbContext API is just wrapper suffering same issues (actually DbContext API suffers even more issues in this scenario and because of that I will skip solution with manually setting relationships).
In short. Once you post your data back to the controller you must create new context instance and attach your Proposal and realated CategoryTags. But after that you must inform the context about changes you did. It means you must say context which tags have been added to proposal and which have been removed. Otherwise context cannot process your changes because it doesn't do any automatic merge with data in database.
The easiest way to solve this is loading current Proposal with related CategoryTags from database (= you will have attached instances) and merge incoming data into attached object graph. It means you will manually remove and add tags based on posted values.