How to assign the same fact instance to different planning entities in Optaplanner - optaplanner

When having two planning entity types (classA and classB) in a single solution, and both need to share a single fact instance, should we use a shadow variable on one entity, mapped to a planning variable on the other entity?


What is aggregates?

I have read the word aggregates many times while reading domain driven design and in some software engineering articles and still, don't know how to use it or understand it properly. Sometimes I call it on Models (classes) and sometimes I miss-up with the aggregation relationship in object-oriented. Is there a good explanation?
Both are different.
In domain driven design, a Bounded Context contains one or more aggregates. Splitting a bounded context into multiple aggregates is coming from the functional requirements.
An aggregate contains collection of classes(see note) and they are functionally related to each other. In other words, the classes in an aggregate shares same transaction (should be saved together in database).
Example: Order class, OrderItems class, OrderType
Enum-Class, Address class.
The above four items can form an aggregate. In this case, Order class acts as Aggregate Root, which must be public and exposed to other layers. Only one aggregate root per aggregate.
Interaction among the aggregates are linked via only aggregate roots.
For further reading:
Note: classes - An aggregate may contain 3 categories of components. They may or may not be class types.
Entities - All entities are classes
Value Objects - It can be a ValueType (it could be a structure in C#)
Enum Classes - Simple enums are bad in domain driven design, so an Enum-class is preferred.

What is DTO equivalent term for objects returned from DAL?

I'm already using DTO's for data transfer over a network. Now I'm also introducing different DTO-like classes to the DAL. This is to avoid passing the application (business) objects across layers.
To avoid naming confusion, I would like to use another term than DTO but can't find a good one.
What is DTO equivalent term for objects returned from DAL?
"What's in a name? that which we call a rose by any other name would smell as sweet." - William Shakespeare
Also, what Martin Fowler says about POJO:
In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.
By the way, it does not matter that much. Looking at your concern to avoid confusion due to similar naming, you may choose from "DataModel", "Entity", "POCO".
Following are very loose considerations for different terms generally used:
Relational Model [Database Layer]:
Database, tables and fields.
Persistence Model [Data Access Layer]:
Model that (generally) belongs to ORMs or closely map with database.
This is used for persistence needs.
Domain Model/Business Model [Business Logic/Services Layer]:
Model that is exposed to BLL/Service Layer.
View Model [UI Layer]:
Model that is exposed to View.
Holds only state and used to transfer data from one layer to other.
Does not have any behaviour/logic except serialization.
Preferably serializable.
Designed against requesting layer; does not resemble with database.
Does NOT have its own identity.
It is simply a regular object that has no references to any specific framework and does not follow their interfaces or restrictions.
Persistence ignorant objects that can be used with any ORM.
Holds data from database.
Not necessarily serializable.
Designed against database request.
May have logic for validation or other that is tightly bound to POCO (like data encryption/uniqueness of column).
Does NOT have persistence methods like Get, Save etc. POCO does not fill itself.
MAY have its own identity.
It MUST have its own identity and can be uniquely identified.
Object that can be loaded from and saved to a database using a DataContext.
Cannot exist without its DataBaseContext.
Tightly bound with specific ORM and implements its rules (default constructor, virutal properties to create runtime proxies etc.).
Entities represent domain model and domain logic.
Common term used to represent any object that holds data.
All objects above, if we put any of it in MV* pattern, it becomes Model.
Refer following answers:

Does it conflict different class instances modifying and saving the same core data object?

In my app I have two instances of two different classes fetching the same core data object and grabbing a pointer to it in their respective properties. Then my two instances they both modify a different attribute in the core data object and save context at different moments. Is this going to create inconsistencies or merge conflicts in my app or will core data manage well this process? I've read about uniquing in the Core Data Programming Guide but I'm not sure I can extrapolate to my case the example they use.
Thank you.
This isn't a merge, it's just an update. There is only one instance of the managed object and multiple different pointers to it. If you check the address of the managed object instance you can verify this. So no, there are no issues (so long as you do all this on the same thread that owns the instance of course).
The uniquing you refer to relates to inserting multiple instances which both have the same unique identifier and is a different situation than you describe.

Shared PKs and ObjectContext errors

I am using EF 4.3 in an ASP.NET WebForms application. I've started with model first approach with context object of type ObjectContext and POCO code generator (via T4).
At the beginning the Context was created at the beginning of every service method. While working on performance I decided to switch to context per web request. Unfortunately I have encountered an issue with Table-per-Type inheritance. I have two entities: Offer and OfferEdit. They are in a one to one relationship, and both share the same primary key. Basically an OfferEdit (OfferEdits table) is created once an Offer is being edited.
I query the context for a particular Offer entity more then once during web request. The error I get trying to execute:
var offer = Context.Offer.Where(o => o.Id == offerId).FirstOrDefault()
when this offer is already loaded to Context.Offer.EntitySet is
All objects in the EntitySet 'RuchEntities.Offer' must have unique primary keys.
However, an instance of type 'Ruch.Data.Model.OfferEdit' and an instance of type'Ruch.Data.Model.Offer' both have the same primary key
Will appreciate all advice.
Sounds like you are misusing TPT inheritance. To make it clear EF inheritance works exactly same way as in .NET - the entity can be either of type Offer or OfferEdit. You can convert OfferEdit to Offer but it is still OfferEdit. It can never be of both types which means you can never have Offer entity with Id same as OfferEdit entity because same key cannot be used by two entity instances. You also never can change instance of Offer to OfferEdit because .NET doesn't allow you changing type of existing instance.

Design pattern for mapping DTOs containing child collections back to domain models

For the longest time I've been using AutoMapper to both map my domain models to my DTOs, as well as mapping my DTO back to domain models.
I'm using EF4 for my ORM, and this mapping gets really ugly when the model being mapped contains child collections that need to be add/updated/removed from. As I move forward with my project I keep running into this problem more and more: photos for a blog post, packages for an order, etc.
When going from DTO->domain model, I end up having to add a BeforeMap call that removes all the entities from the domain model's collection and then add a custom ValueResolver for the collection that takes the PK of each entity from the DTO, grabs it from the DB (so that Entity Framework doesn't think I'm adding a new entity), and re-adds it to the domain model's collection and then apply any updates to the individual fields.
This is a really ugly solution, but so are my attempts to manually handle updating these collections. Does anyone have any suggestions for a cleaner approach?
You may want to use ValueInjecter instead of AutoMapper for this functionality. Check out this question where the makers of both weigh in, AutoMapper vs ValueInjecter . I haven't personally used Value Injecter, but it was built to do what you are trying to do. AutoMapper is better for flattening, but the author of AutoMapper admits that it is not a good tool for "Unflattening", which is what you are trying to do.
Because of very bad experience with updating detached object graph I always first load actual object graph from database and manually merge my DTO into this object graph. I usually end up with several helper Merger classes with methods merging DTOs (or view models) to Domain objects. I'm also still looking for better solution.
I also tryed solution where I didn't load object graph from database first. Instead I used custom adapters to build detached domain object graph, attached it to context and set states of all objects and relations. But it was wrong and extremely complex way which couldn't be used for all scenarios (combination of updates and inserts of subentities could not be handled without additional transfered data about initial state).
In hibernate there is a cascade option where the updates from to the children..
I think NHibernate has a similar cascadeAll option.
If you can relay on the assumption that the DTO's child collection is
probably the most updated version, you can actually replace the old
collection with the new one.
We had the same issue with NHibernate and
we solved it like this:
Use ConstructWith to pull the entity out of the database using the
dto's id.
Use BeforeMap to CLEAR the entire child collection (make sure that
the reference on the child will be set to null as well).
AutoMapper will automatically copy the new collection.
Luckily, NHibernate was smart enough to apply changes only, I can't
tell if EF does the same.
This isn't a perfect solution, but it works for a simple domain model.