I have a simple Entity-diagram (crows foot) in Visio 2016. When I draw relationships between the entities, they can be glued to the entity, an attribute or a connection point. This is all good, but very often when I move an entity around on the page, the endpoints of the Relationship, that was attached to the entity, will suddenly become unglued (hanging loose without any connection).
Is there any way to keep them hanging on to the entity?
Yes, don't move the connectors, only the entities themselves.
Related
I am designing a RESTful API and my questions is the following: What is the best practice for managing relationships using POST and PATCH in a RESTful API? Where and when should I allow the consumer of the API to establish relationships between entities when the opposite entity/entities already exists/exist? My goals are to (a) minimize code and code maintenance with (b) a balanced ratio of easiness to understand the API and number of API calls to establish relationships. The most limiting criterion is that I am developing and maintaining the API on my own.
If it is of any interest, I am using ASP.NET Core and separated the API (with outer facing models) and the entity framework based data layer (with data models) into two different layers, where the API layer references the data layer (API -> Data).
I would like to discuss all possible combinations of the http request methods POST and PATCH and the three types of relationships one-to-one, one-to-many and many-to-many.
POST one-to-one
I was thinking about allowing the consumer of the API to let the POST request for the new entity only go through when the opposite entity has no relationship to any other entity of the posted entity type.
Another option would be to never allow setting relationships through POST but only let it update via PATCH. I favor this option, because it makes the entity easier and saver to create when treating the relationships separately. Even better, it would only require two API calls - one for POSTing the new entity and one for PATCHing even multiple relationships to many different one-to-one opposite entities.
POST one-to-many
One option would be allowing the consumer of the API to let the POST for the new entity only go through when all of the opposite entities have no relationship to any other entity of the posted entity type. Less save would be to allow the consumer to override existing relationships of the opposite entity to another entity of the type of the posted entity.
Another option would be to not allow posting any relationship of a single entity to many entities, because the relationships are effectively set in the opposite entities anyway. I prefer to only allow setting the relationship in the opposite entities via PATCH since this is the place where the many to one relationship is effectively established, and it keeps the creation of the entity separated from establishing relationships.
POST many-to-many
I would never allow to set a relationship for a POST request in a many-to-many relationship, but only allow to PATCH new relationships on both the new entity and the opposite entity. Due to the complexity of this type of relationship, I think it is best keep the entity creation as easy as possible and manage relationships separately through PATCH requests.
PATCH one-to-one
I would set no restrictions and allow the consumer of the API to set the relationship freely on both sides.
PATCH one-to-many
This one is a real dilemma for me - number of API calls vs easiness to understand relationships and lines of code.
On the one hand, I could allow to PATCH from the single entity point of view (it contains for example an array of opposite entity IDs). This would require only one API call to update the relationships of the multiple opposite entities, but this requires more code, because the data layer needs find and loop through all opposite entities. In addition, updating from the single entity point of view is sometimes hard to understand for me - many times its easier for me to establish the relationships in all opposite entities that refer to the same single entity.
On the other hand, I could allow the consumer of the API to update all opposite entities individually. This would require many API calls, but I sometimes think updating from this point of view is easier to understand, and the relationship is effectively set in the multiple opposite entities anyway.
I don't know what to favor yet. I am thinking about offering both options.
PATCH many-to-many
The only way I can see is to allow the consumer of the API to allow setting relationships on both sides due to the nature of this relationship.
While elaborating my ideas above, I think the best guideline is to keep creation of entities completely separated from establishing relationships and to set the relationships only where they are effectively established (mimicking SQL table behavior). I assume the latter one is what most API consumers should be familiar with and the first one keeps the API save and simple (at the cost of efficiency).
Please let me know if I missed any cases, criteria for decision making or didn't think of any implementation strategies.
Best regards,
philippfx
I'm a bit confused about this naming convention.
What is the difference between them and are target/source interchangeable with owning/not owning?
One thing in particular is hard to understand:
"The main difference between a OneToOne and a ManyToOne relationship in JPA is that a ManyToOne always contains a foreign key from the source object's table to the target object's table, where as a OneToOne relationship the foreign key may either be in the source object's table or the target object's table"
JPA wikibooks
I can't imagine such situation in uni one-to-one
Differences between them are a little confusing. You should practice a lot to understand very well.
At first, you should understand some terminology:
Role : In every relationship there are two entities that are related to one another, and each entity is said to play a role in the relationship.
Direction : Relationships can be unidirectional or bidirectional. For e.g.. a Person has an address is normally unidirectional whereas Employee working on a project is normally bidirectional. We will look at how to identify and define directionality while coming up with a Data Model.
In order to have relationships at all, there has to be a way to create, remove, and maintain them. The basic way this is done is by an entity having a relationship attribute that refers to its related entity in a way that identifies it as playing the other role of the relationship. It is often the case that the other entity, in turn, has an attribute that points back to the original entity. When each entity points to the other, the relationship is bidirectional. If only one entity has a pointer to the other, the relationship is said to be unidirectional. A relationship from an Employee to the Project that they work on would be bidirectional. The Employee should know its Project, and the Project should point to the Employee working on it. A UML model of this relationship is shown here. The arrows going in both directions indicate the bidirectionality of the relationship (Form this book >> Pro JPA 2)
Then dive into this link (archived from the original)
I'd like to comment only the links, but I need 50 reputation
I have started using Entity Framework Code First for the first time and am impressed by the way in which our greenfield application is being built around the domain rather than around the relational database tables (which is how I have worked for years).
So, we are building entities in C# that are being reflected in the database every time we do a new migration.
My question is this: should these same entities (i.e. designed with Entity Framework in mind) play the same role as entities in Domain Driven Design (i.e. representing the core of the domain)?
Object-Relational Mapping and Domain-Driven Design are two orthogonal concerns.
ORM
An ORM is just here to bridge the gap between the relational data model residing in your database and an object model, any object model.
An Entity as defined by EF concretely means any object that you wish to map some subpart of your relational model to (and from). It turns out that the EF creators wanted to give a business connotation to those by naming them Entities, but in the end nothing forces you that way. You could map to View Models for all it cares.
DDD
From a DDD perspective, there's no such thing as "an Entity designed with EF in mind". A DDD Entity should be persistence ignorant and bear no trace of any ORM. The domain layer has no interest in how, where, whether or when its objects are stored.
Where the two meet
The only point where the two orthogonal concepts intersect is when the object model targeted by your ORM mapping is precisely your domain model. This is possible with what EF calls "Code first" (but should really be named regular ORM), by pointing to your DDD Entities in separate EF mapping files living in a non-domain layer, and refraining from using EF artifacts such as data annotations directly in your Entity classes. This is not possible when using Database First, because the DDD "purity" part of the deal wouldn't be met.
In short, the terms collide, but they should really be conceptually considered as two different things. One is the domain object itself and the other is a pointer that can indicate the same bunch of code, but it could point to pretty much anything else.
They shouldn't be the same as they're designed for different purposes. An ORM entity is a facade for 1 or more tables, its purpose is to simulate OOP on top of relational tables. A Domain Entity is about defining a Domain concept. If your Domain Entity turns out to be just a data structure, then you can reuse it as an EF entity, but that's just one case.
A DDD app never knows about EF or ORM. It only knows about a Repository. Hence, your Domain Objects (DO) don't know either about EF. You can choose to consider them EF entities, as an implementation detail, BUT... you should do that ONLY after your DOs are defined and their use cases implemented. You should defer as much as possible the implementation of persistence (use in-memory repos (lists) for devel).
When you reach that point you'll know if you can reuse your DO for ORM purposes or if you'll need other ways (such as a memento).
Note that a design of a DO while driven by the Domain, it should take into consideration the persistence issue, but it shouldn't be influenced by it i.e don't design your DO according to the db schema. The persistence strategy can be different for each DO and it might involve or not an ORM.
If you're using Event Sourcing for a DO, ORM doesn't exist. Same for serialized objects. It matters a lot how an object will be used by the app (updating and querying), that's why I've said you should defer the persistence implementation. For a lot of DOs you won't need a rdbms (even if you're using it) so an ORM entity will look more like a KeyValuePair (Id => serialized data).
In conclusion, they are different things for different purposes, that might look identical for some cases (CRUD scenarios).
I would say, they can be the same.
Sometimes there is no need to support two models. When you follow code first approach, your entities model your domain, your infrastructure (ORM) separates domain and persistence layers.
It might be reasonable to maintain two models if you have legacy database and have to maintain it.
There are two other SO questions that can be helpful:
Repository pattern and mapping between domain models and Entity Framework
Advice on mapping of entities to domain objects
Well.That's The Approach i use.And I've seen a lot of others doing the same.Now am using The Onion Architecture/Pattern to Create my application and making Everything rely on the domain entities made my life easier.because whenever i want to change for example the Layer that deal with my database ,i can do that without changing the UI layer(ASP.NET MVC app,WPF app...etc)...I suggest doing the same.
let's wait for other posts
I agree with what MikeSW said (3rd Answer).When you design your domain entities,you should do that without caring about who will consume those entities (ORMs or any other technology serving whatever purpose).design them with one idea in mind : they will be reusable and they will not need to be changed in the future (hopefully)
If you have used the Entity Framework then you know the EDMX is cool. You also know it can become HUGE and almost unmanageable.
When it gets large, it is tempting to create a second EDMX or third - even one for each Schema in your database (just as an example).
Such a seperation would help with organization of your EDMX, but it could seperate the context of entities in the same namespace.
Moreover, seperate EDMX files can create a situation where a JOIN operation across EDMX files results in excessive, redundant database communication.
But, the fact remains, the larger the EDMX, the more difficult it is to use. The more difficult it is to ensure it is correct. The easier it is to break.
Do you break your EDMX files apart? Do you have a rule of thumb for when to it?
One example for the need to split your EDMX would be
if you have a group of entities that are used in more than one project,
while others are project-specific and you are willing to forsake having navigation properties between the parts (and remain with only exposed FKs).
You can automatically merge the EDMXs into one if you want to maintain the separately, but open up a context to them all and query as one. This requires that they share the same namespace.
We've only gone as far as needing to use two separate EDMX in a single solution. This separation occurred for us with an EDMX for domain specific model entities and another for those more common across all of our solutions (Payment as an example). Logically you could say this for us was at the db schema level although that wasn't the hard rule of the separation.
Whilst we didn't have a requirement for joins across them we did need transactions. We accomplished this with a reusable UnitOfWorkContainer that would wrap the EF contexts within a TransactionScope. The contexts would be injected through DI into the container and we would only use the TransactionScope if there was more than one context held in the container.
The container itself implemented our IUnitOfWork interface so it was dead easy to plug into the existing codebase.
In Core Data, most of the time relationships are modeled bidirectional. But the docs say in another place:
It typically only makes sense to model
a to-one relationship in one
direction.
Within Core Data you should always use a bi-directional relationship unless you have an extreme edge case. If you use one directional relationships then you are going to incur performance penalties within core data itself as well as have issues with referential integrity.
Unless you know specifically why you need a uni-directional relationship then you should always do a bi-directional relationship; the rule is that simple.
While Franci's answer is interesting, I have to disagree with it. Even in the examples he provided you should have a bi-directional relationship. There are almost no situations where a uni-directional relationship is going to be a better fit.
The answer is determined by the referential integrity requirements you want to enforce. If updating or removing the object on either side affects the object on the other side of the relationship, you need two-way. However, if updating/removing the object on one side does not affect the object on the other, then a one way is a better model.
Take for example a parent-children model with a 0..n : 1 cardinality (I prefer the 1 : 0..n representation, but for the sake of argument let's reverse it). Adding a new child, updating an existing child or deleting a child has no effect on the parent object, so there's no need for the parent to know explicitly about all the children (except when it comes time to pay college tuition). However, removing the parent has an adverse effect on the children objects, as they need to be deleted or re-parented, otherwise are orphaned and in an invalid state. Thus, it's better to model it as a one-way relationship. Another example is inventory - parts catalog relationship, again with 0..n : 1 cardinality.
It's a matter of ownership: usually it doesn't make sense to have a bidirectional relationship because an entity conceptually owns the other one.
Think about some examples. If you have a structure in which you have users and an user can have a simple bank account associated with him. If you make the relation bidirectional you mean that an user owns an account but also an account owns an user.
This will make sense because you don't want to delete an user whenever you delete his account. That's why usually you don't need to have it bidirectional: because it's an additional constraint that is not needed since most of the time you will have an entity that has the other but not vice-versa.
I think you read the whole document about relations you referenced in your question.
The document also describes all disadvantages of using unidirectional relations, and that only under very rare circumstances it makes sense to create unidirectional relations.
As a general rule i would strongly recommend creating bidirectional relations, except you are knowing exactly why not to do so.