I have Person class which is root of its aggregate, this aggregate also contains country and state province as vo.
{Person, Country, StateProvince} - > Person is root aggregate.
//
Public Person(string name, string country, state province,{other params}){}
// But now i am facing problem in UI, how will i populate Dropdown for Country and Stateprovince, through person because it is root aggregate, but i don't want any person's assigned Country or Stateprovince but i want list of all countries and their Stateprovince, so that user choose one from them
Do i manually create table for country and stateprovince and fill them with all values manually.If yes, then how will i get values from those tables in ddd .
Your model is trying to tell you something.
Country and StateProvince are probably not part of the Person Aggregate.
Remember the very handy "delete test" for an aggregate, ask if I delete this person do I also delete their country and StateProvince? I live in Canada, and you remove me from your system are you also going to delete the country Canada from your system as well?
No, you would not. You have two separate aggregates here Person and Location which would contain the Aggregate of {Country, StateProvince} If you delete a country you would very likely also delete all the states or provinces contained within it as well.
Just because Person references a class or has-a class doesn't make all the references part of that aggregate. Location is very common aggregate in many systems and regularly stands on it's own.
You should have a Person Repository that utilizes a LocationRepository and have the UI directly call the LocationRepository to obtain Location Aggregates.
You would populate your country and state province from different tables. You would then fill the drop downs from these tables. When working with a specific Person entity which has already got Country and StateProvince assigned you would bind them with master tables through id.
Hope that helps.
Related
Suppose I have a User entity. And this entity must have a Country field.
As a rule, Country is a Value Object.
And here it's kind of okay, and there's no problem.
But I got a ticket, which says that now on Frontend, Country must be filled in from the list of available Country (also I need to expand this list in the future)
This would be an easy task if Country was originally an entity, but I have it as a Value Object.
What to do in this case? Redefine Country as an entity, or is there another way?
Even when you maintain Countries as entities, you can store them as part of the User entity as a Value Object. The fundamental nature of a country object is such that its value is its identity, making it a good candidate for a Value object.
But IMHO, the list of Countries can be preserved as a static list because the list is finite.
I don't know what it means for your app to add a country to the list, but I am assuming that it is not as trivial as a CRUD op. If the list is rarely updated, you can maintain the list of available countries as a static list in code that is updated when necessary.
If the requirement is to often switch a country from available to not-available and vice-versa, you can store them as CRUD entities but use them as Value Objects in User.
I am having 1 form with 3 fields.
1st field is country,2nd field is state and 3rd field is city.
I configured the values for this fields from other form.
The problem is when i select country it has to display states come under that country and same like for city also.when i select a state it has to display the cities come under that state only.
You need resource documents, where you get the values of states and cities from. Either make a document for each country (containing the states) and for each state (containing the cities) or make only one document containing the states and cities in seperate fields.
Depending on the key (the country selected in your country field) use #DbLookup in your selection formula of the dialogue fields to find the right document/field (depending on which method you use).
In the properties for your Country and State fields, you need to make sure that you have the "Refresh fields on keyword change" property checked. And on the State and City fields, you need to make sure that you have the "Refresh choices on document refresh" proprety checked.
Then you will need a mechanism to do the lookups.The best way is as described by #Lesic's answer. I.e., you e view called "(LookupStates)" where the key column is Country, and a view called "(LookupCities)" where the key column is Country+State. You will pre-populate these views with documents containing the Country, State and City fields. And on your form, the formula for choices in the State field will do an #DbLookup call to the (LookupStates) view and the formula for choices in the City field with do an #DbLookup call to the (LookupCities) field.
Note that both of the formulas have to guard against error cases as well. I.e., the formula for State choices needs to check to make sure that Country is not blank, and the formula for the City choices needs to make sure that Country and State are not blank.
I have two forms that are related and I would to combine them in a view control. Not that difficult. This is for a "1 to Many" type scenario.
Say I have a customer view with the columns customerID and Customer Name. Then I have a view showing the "many" documents that has the columns masterCustomerID, orderNumber, orderDate.
On the XPage I create a view control of the many documents and add the columns masterCustomerID, orderNumber, orderDate. Then I add a column in the front to do a DbLookup to pull in the actual name of the customer. Nothing too fancy really.
My question is, in this situation, where the lookup column is the FIRST column. What are the strategies to sort the view column by that column. By default it would sort by the Key Value in the order view which is likely different then the Name values.
I'm not averse to using repeat controls if that would be easier.
My first thought would be to employ TreeMaps somehow, but I don't know if that's practical in the event that there might be a LOT of documents. Maybe there's something I'm missing...
Any advice would be appreciated. Thanks
Use view with (Customer name, Customer ID) structure as main view. Then based on Customer ID populate other columns by lookup from view with structure (Customer ID, Order ID, Order date). Hence it is 1:N relationship, you can't use single view component, but two nested - repeat inside view column would do.
I hope you are aware of performance impact (orders looked up for every customer row), so don't try to show too many customers at once.
I'm starting to learn and practice some CoreData, with no programming experience.
After searching in Web, looking for Apple samples and reading some books, I´m still stucked in one point.
I have two entities (Expenses and Month) with reciprocal relationships called "monthsOfExpense" and "expensesOfmonth" and I'm showing in a tableView the expenses of a single month.
My problem is to insert new expenses and save them: I've a view to insert new expenses where the user can insert the name of Expense, the value and the months that expense is valid (associated with the monthsOfExpense relationship, i hope).
I'm ok saving the name and the value of Expense entity, taking the string and NSDecimal number from the textFields.
My problem is how to associate that expense to a particular or several months? How can I save a textField.text as a relationship, indicating to what month an Expense belongs?
I'm starting with a textField where the user can insert a month, assuming that an Expense is valid for one month only (for learning purposes and simplification).
My idea is to allow the user to select several months (using maybe another tableView with selectable months) and association of an Expense to different months.
I know that a relationship comes as a NSSet, but I'm not being competent to save the attributes and the relationship from a View, at the same time.
Hope was cleared and many thanks in advance for trying to help.
OK. In Core data, you define your "Expense" entity, create a relationship to "Month" entity. Now create class files for these 2 entities. Then you use it by
Expense *expense1 = [NSEntityDescription insertNewObjectForEntityName:#"Expense" ....
Month *month1 = [context executeFetchRequest:......];
expense1.month = month1;
...
[context save];
In your situation, you can predefine 12 "Month" objects, giving the month name as the text property.
Then you can lookup these month objects using NSFetchRequest. Add the relevant month objects to your expense using
[expense addMonthObject:month]
Then save your managed object context.
You message the managed object for its mutableSetValueForKey:RelationshipKey,
then you add the to-many managed objects to that set. CoreData completes the other half of the relationship data.
SharePoint Lookup field, what is it?
Please share, thanks.
It is a type of field used to indicate that the possible values of a column in a list must be taken from the elements of another list. For example, if you have a list of users, and one column of this list is the country, you can create a lookup field pointing to another list "countries" which contains the possible values to select.
If you think in terms of relational databases, a lookup field is a foreign key: you only store a reference to the related item, not its value.
For instance, you have a list of meeting rooms. You can create a meeting calendar by creating a new calendar list with a lookup to the "Meeting rooms" list. Hence, when organizing a meeting, you will be able to pick a room from the list of meeting rooms entered previously.
A "Lookup" differs from "Choice" field as you may alter the source item and the referencing item is updated automatically. For instance, you change the name of a meeting room - all meetings booked for that room will show the new title automatically.