I have doubts about what is the best approach to publish my domain events. I have two use cases:
The user can create a question with answers
The user can add an answer to a given question
One of the invariants are:
A question must have at least 2 answers and at maximum 5 answers.
I have designed a aggregate Question with a list of Answer entities, and it Question constructor I verify that invariant.
Related to first use case, my doubt is related on the domain event I should publish.
My first approach is this domain event:
public class QuestionCreated {
private final String questionText;
private final List<Answer> answers;
}
I don't feel good with answers property because it is a list of Answer entity, but I don't know how do it better.
Or second approach, would you do two domain events QuestionCreated and AnswerCreated and when I create a question, the aggregate will publish a QuestionCreated event and one AnswerCreated for each answer in answers list?
For the second use case, add an answer to question, following the aggregates principles, I would save the Question aggregate, with the new answer. In this case I also have doubts about the domain event to publish, a QuestionUpdated, similar to QuestionCreated, or AnswerAdded only with the answer information.
Thanks!
Since a question can't exist with zero or one answers, I think it's overall better to include at least two answers in the "genesis" event for Question (i.e. QuestionCreated). Otherwise, you'll have to model a proto-question which has zero or one answers and be sure to never treat that as a Question.
For the adding an answer case, it's generally a good practice to avoid Updated events, because a major part of the value in modeling domain events is that they express the context (e.g. the "why") of the change in addition to what changed. Updated events don't capture that context. So I'd definitely use an AnswerAdded event.
I would strongly consider having the QuestionCreated event have exactly two answers:
public class QuestionCreated {
private final String questionText;
private final Answer firstAnswer;
private final Answer secondAnswer;
}
If 3-5 answers were supplied at creation, those would then be emitted as AnswerAdded events (or the otherwise identical but differently named to capture context AnswerCreated). By encoding QuestionCreated in this way, we ensure that there's no way to express the creation event with fewer than 2 answers ("make illegal states unrepresentable"... we'll handwave away null), and we also allow at least the possibility of not allocating a List.
Related
I'm new to Redux-Saga, so please assume very shaky foundational knowledge.
In Redux, I am able to define an action and a subsequent reducer to handle that action. In my reducer, i can do just about whatever i want, such as 'delete all' of a specific state tree node, eg.
switch action.type
...
case 'DESTROY_ALL_ORDERS'
return {
...state,
orders: []
}
However, it seems to me (after reading the docs), that reducers are defined by Saga, and you have access to them in the form of certain given CRUD verb prefixes with invocation post fixes. E.g.
fetchStart, destroyStart
My instinct is to use destroyStart, but the method accepts a model instance, not a collection, i.e. it only can destroy a given resource instance (in my case, one Order).
TL;DR
Is there a destroyStart equivalent for a group of records at once?
If not, is there a way i can add custom behavior to the Saga created reducers?
What have a missed? Feel free to be as mean as you want, I have no idea what i'm doing but when you are done roasting me do me a favor and point me in the right direction.
EDIT:
To clarify, I'm not trying to delete records from my database. I only want to clear the Redux store of all 'Order' Records.
Two key bit's of knowledge were gained here.
My team is using a library called redux-api-resources which to some extent I was conflating with Saga. This library was created by a former employee, and adds about as much complexity as it removes. I would not recommend it. DestroyStart is provided by this library, and not specifically related to Saga. However the answer for anyone using this library (redux-api-resources) is no, there is no bulk destroy action.
Reducers are created by Saga, as pointed out in the above comments by #Chad S.. The mistake in my thinking was that I believed I should somehow crack open this reducer and fill it with complex logic. The 'Saga' way to do this is to put logic in your generator function, which is where you (can) define your control flow. I make no claim that this is best practice, only that this is how I managed to get my code working.
I know very little about Saga and Redux in general, so please take these answers with a grain of salt.
I'm looking to share an EF Context between "data manager" objects to ensure change tracking occurs under one context as opposed to handling multiple contexts...so I'm looking into named context... but in review of this documentation, I felt it wasn't clear, and I want to ensure my assumption is correct, and if so, update the documentation: here PRISM documents the resolution of named instances via a constructor:
My assumption is that the named typed "carservice" is matched to the named parameter in the constructor to select which concrete class should be reference to that parameter based on the IVehicleService.
Is my assumption correct - either way I'll create a pull request to clarify the documentation..Either way, answering the question here will add reference to clarification/handling of named instances in PRISM.
It seems this is NOT correct assumption, and it's not possible in Unity - I refactored to avoid.
One solution that I didn't try was to simply another interface (came to mind much later), was inheriting from an existing interface, and registers the "new" interface to use a specific constructor. As I'm new to Unity, I thought I would mention. I'm answering my own question, as I can't don't think I can give credit to a comment, and I HATE leaving questions unanswered on this site!
I’m going through preparation for a professional assessment and at the moment I have a question that I can’t give a complete answer to, as I am new to Apex.
Question: Describe the features of static methods. What methods(necessarily) must be static?
There are no problems with the first part, but I would like to find an exhaustive answer somewhere in the second part. Annotations # Future for example, etc.
static methods need to be used when you don't need an instance of a class or if the method needs to be exposed to other callers. Examples of this are lwc/aura/visualforce remoting methods.
See these links for examples of why static is necessary
https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_apex.htm
https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.apex
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_annotation_RemoteAction.htm
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
In repository examples, I see the repository instantiated when the Session opens, which seems as if it is around for the entire Session. In controller actions, the data layer is then accessed through calls to the repository. Is this common practice? Wouldn't it make more sense to be instantiating the repository in an on need basis per action request?
Edit: A more exact scenario.
public class myController : Controller {
IMyRepository myRepository;
public myController(IMyRepository repositoryParam){
myRepository = repositoryParam;
}
public ActionResult someAction(){
MyClass myClass = myRepository.RepositoryAction();
}
}
In this scenario, myRepository is global to myController (note: this is based off an example from Steven Sanderson). I have seen it also defined for all controllers to access, but this is a simple, exact, example. In this example, why would the repository be used globally instead of on a per use basis?
To answer your question, Travis, you should read up a bit on the Repository Pattern. This pattern is used to provide a number of advantages, including:
It centralizes the data logic or Web service access logic.
It provides a substitution point for the unit tests.
It provides a flexible architecture that can be adapted as the overall design of the application evolves.
As to your question: "Is this a common practice?" the answer is, "It should be." but, unfortunately, I don't see it as much as I would prefer.
Now, in your example, you show the repository being created within the context of your controller class. (Please note that this is NOT the same thing as an object being made "global" as you put it. Global means that the object is accessible from any scope. Read more about it here at Wikipedia.)
In any case, one of the advantages is that the repository allows you to change between how you are accessing your data (or even where your data is being accessed) by using the correct, concrete version of the repository. So, you may have:
IRepository - Your interface which the concrete repositories implement.
DatabaseRepository - Accesses your data in a database.
FlatFileRepository - Access your data out of a flat file.
etc.
If you wish to switch to other data sources, it is a simple as swapping out the concrete implementation in your controller. (Please note, there are more advanced and flexible ways of doing this through dependency injection, but that is out of scope of this question, although it does/can play heavily in the repository pattern.)
In any case, say your project team decides "Hey, we're going to switch from storing all our data in flat files to using a database." Well, if you have scattered the instantiations of that specific repository throughout your code, you now have a lot of different areas to fix and update, somewhat negating the advantages of the repository pattern. However, by declaring a member repository of your controller, you just switch from a FlatFileRepository to a DatabaseRepository, implement the new repository, and you are finished! Everybody on the team is happy!
Update: "Why Instantiate a Class Variable?"
To answer that question, you have to think of your two options. The first option is that you could hold a relatively small object in memory. The other alternative is you could instantiate a new object in memory every time that a user needs to access one of your actions causing new memory to be allocated (and deallocated when you leave the scope that the object was in) and requiring more work by the server which is hosting your web app.
If you think about how a website is used, users are hitting those actions on a frequent basis. Every action signifies a portion of your website. If you instantiated every single time you needed the repository, you would quickly give the server a much bigger workload than it actually needs - particularly as your site grows in size. (I am sure other folks can think of other reasons why you would want to do it the way shown in the tutorial vs. instantiation in each individual action.)
And, then, of course, there is the refactoring issue as I mentioned above. That is about "efficiency of making changes" or improving the maintainability.
Hope that helps you a bit more and better answers your question!
I search with reflector and I didn't manage to find a case where the ValidationResult.MemberNames is supposed to contain more than one value.
So, first of all I am wondering why MS had to do it IEnumerable<string>, then now that they already did this, can I rely that this property will only return one value?
Update
Concerning the DataAnnotations validation system I find more sloppiness:
The TryValidateProperty and TryValidateObject should have removed the errors from the validationResults parameter if they don't exist any more.
ValidationResult should have overriden Equals and GetHashCode.
Why is the ValidationResult.ErrorMessage mutable!? I can't event build an EqualityComparer myself!
If the DataTypeAttribute is only used for representation concerns, why does it inherit ValidationAttribute, that's just misleading, I had to struggle till I understood (after reflectoring) that its not going to work. MS just didn't implement it.
And the list goes on.
Consider Password and PasswordConfirmation. Or any Start/Stop values, or any other cross-field validation.