I have an application built with NestJS and TypeORM.
There's an entity with an owner (user_id for example), and there are user roles.
So I wanted to find out if there is an elegant way to allow an “Admin” for example to list and edit all entities and all other roles to list and edit only entities that they own, with their user_id.
Of course, I could do this by writing some code, but I wonder if there's a nice unified approach so I don't have to reinvent the wheel.
I'm working on an ASP.Net Core MVC 2.0 application using Entity Framework Core 2.0. I need to upload a file related to an entity that is getting created by this application.
For example, imagine having to upload an invoice PDF as part of creating a payment entity. This should be a one-to-one relationship.
I'm having some trouble deciding how this should be represented in the Entity Framework data (and object) model. I found some guidelines that say that the entity foreign key should exist on the dependent object. In this case, the invoice would be the dependent object, so I should add the payment ID to the invoice object.
But I won't be downloading the invoice object as often as I would the payment object. And I was planning on a flow where the payment view would have a link to an action on the invoice controller to download the invoice using the invoice ID. So having the Invoice ID on the Payment object would make sense.
So I'm not sure of the best way to handle this.
As an aside, I've seen plenty of samples with uploading/downloading files, but not many that shows them how this might look when the files are associated with an entity in the database.
Does anyone have any suggestions?
I don't have any code that I can share at the moment; if anyone thinks code might help, I can throw something together.
Thanks in advance!
Just wanted to point out that Gert Arnold's comment was the correct answer; the following has examples of how to model one-to-one relationships.
https://learn.microsoft.com/en-us/ef/core/modeling/relationships
Thanks Gert!
I'm building an api using asp.net web api for an application that needs to track all the activities performed by users. So in every table I need to have createdUser and updatedUser field with their dates. But I faced some challenges on how to go about.
Here are my concerns:
How can I have that in the User table itself? Which type of relationship do I need for that?
I have a privilege table than can be created by required users. What type of relationship can I have between the Privilege and the User table?
I'm new to Entity Framework so I need some guides. Please can anyone be very kind to provide some help. Thank you
I don't think u wil need to have that logic in the user table itself.
U can add extra colomn's to each table with CreUser,CreDate, LModUser, LModDate.
Or U can create an extra table like
Entity_ID, Record_ID, User_ID, ModDate, IsCreated.
(or with other logic)
search for many to many relations on google. or:
How to create a many-to-many mapping in Entity Framework?
this is a nice tutorial for all kind of relationships in EF for core
http://www.learnentityframeworkcore.com/configuration/one-to-many-relationship-configuration
I am trying to figure out how to address this issue:
I have 3 tables with a many-to-many relationship.
Users *-* Roles *-* Permissions
I use a ORM to obtain data from them.
A method of my business layer must return users per permission, so I return objects with this class:
public class UsersPerPermission
{
public User[] {get;set;}
public Permission {get;set;}
}
But this class does not map to any table in the repository, it is something I generate from the existent tables. Where should this class live?
In other words:
Should I have a IRepository.GetUsersPerPermission()? And then that class should live in the repository.
Or should I have a IBusinessLayer.GetUsersPerPermission()? And then I have to invoke the CRUD methods in the repository?
It makes sense to put it in the business layer only, because the repository should just expose CRUD operations to tables... BUT, in order to execute this operation from the Business layer, I would have to execute several independent queries to get the data and create the 'UserPerPermission' class. In the other hand, if I place it in the repository, I can get that information in one shot using grouping.
Thanks!
PS: What is the name of this intermediate objects? 'transformations'?
In DDD, most entities and value objects should correspond to identified domain concepts that are part of your ubiquitous language. I usually try to limit many-to-many relationships and artificial association objects as much as possible. Eric Evans describes a few techniques allowing that in his book. When I have to create an association object, it must have a meaningful name with regard to the domain, basically I never name it Class1ToClass2.
In your scenario, it's even more artificial since your object :
Redundantly models an association that already exists (indirectly) in the original model.
Has a name that doesn't reflect any particular business concept.
Note that this kind of object wouldn't be useless if we were in the presentation or application layer as it could come in handy to have a structure containing exactly what is displayed on the screen (DTO). But I'm talking about the domain layer here, which should be devoid of such composite objects.
So I wouldn't create a UsersPerPermission class in the first place. If what you want is a list of users and User is an aggregate root, just create a GetUsersByPermission() method in UserRepository. It doesn't mean that you can't have a GetUsersByPermission() method in an application service as well, if it matches a use case of your application (a screen that displays the details of one permission and the list of users with that permission).
I agree with guillaume31 that there is no need to introduce a domain object "UsersPerPermission" to support a single use case.
There are two ways you can implement your use case using existing domain classes "User", "Role" and "Permission".
Solution one:
Assume you have: Permission --> Role --> User
Arrow denotes navigability. A Permission has association to a list of Roles and a Role has association to a list of Users.
I would add a method GetPermittedUsers() : List<User> to the Permission class, which is trivial to implement.
Th UI logic will invoke GetPermissions() of PermissionRepository then call GetPermittedUsers() on each Permission.
I assume that you use a ORM framework like hibernate(Nhibernate) and defines the many-to-many relationships correctly. If you defines eager loading for Role and User from Permission, the ORM will generate a query that joins Permission, Role and User tables together and load everything in one go. If you defines lazy loading for Role and User, you will load a list of Permissions in one query when you call PermissionRepository, and then load all associated Roles and Users in another query. Everything is load from database with up to three queries maximum. This is called a 1+n problem which most ORMs handle properly.
Solution two:
Assume you have: User --> Role --> Permission
Arrow denotes navigability. A User has a list of Roles. A role has a list of Permission.
I'd add getUsersByPermissions(List<long> permissionIds) : List<Users> to the UserRepository, and add getPermissions() : List<Permission> to the User class.
The implementation of the UserRepository need to join the User, Role and Permission tables together in a single query and load everything in one go. Again, most ORMs will handle it correctly.
Once you have a list of Users, you can create a method to build a Map<Permission, List<User>> quite easily.
To be honest, I muck like the solution one. I avoid to write a complicate method to convert a List of Users to to a map of Permission and Users, hence I don't need to worry about where to put this method. However solution one may create cyclic relationship between User, Role and Permission classes if you already have navigability in another direction. Some people don't like cyclic relationship. I think the cyclic relationship is acceptable even necessary sometime if you user cases demand it.
In a similar context I used a query method in a domain service that returns something like an
IEnumerable<KeyValuePair<PermissionName, IEnumerable<Username>>>
By using the KeyValuePair<> I avoided to pollute the domain model with an artificial concept (like UsersPerPermition). Moreover such a structure is immutable.
I didn't used a query method on the repository because, in my context, no entity was coupled with the other. So it wasn't matter for any of the repositories.
However this solution is useful for your GUI, if and only if you modelled correctly the identifiers of your entities (in your example both Permissions and Users are entities).
Indeed if they are shared identifiers that belong to the ubiquitous language that your users understand, they will be enough without further descriptions.
Otherwise you are just building a useful DTO for your GUI. It does not belong to the domain thus you should use the simplest possible thing that works (an ADO.NET query? something even simpler?).
Indeed, in my own scenario both the GUI and the domain used such a service (the GUI showing a preview of an elaboration).
In general, the domain model must mirror the domain expert's language, capturing the knowledge relevant to the bounded context. Everything else must be outside the domain (but most of time can be expressed in terms of the domain's value objects).
Im using dynamics CRM 2011.
I took a look at the entity called contact.
This entity has a fullname primary field that is automatically populated.
This field is not visible to the crm user when creating a new contact.
I was wondering how do I achieve the same with custom entities?
Do I use workflow to update the primary key field and hide the field from the crm users?
Thanks
That would be one (and the easiest) way to do it, stick a workflow on the create and update of the relevant fields - though users would have to wait a couple of minutes to see the change.
Other options could be a plugin if you want the field to be updated synchronously, or you could use JavaScript to show the field before the record is saved.
You could use the a AutoNumber Plugin here, there is one on CodePlex (I havent used it myself): http://crm2011autonumber.codeplex.com/