I have sample project for identity customization using
Install-Package Microsoft.AspNet.Identity.Samples -pre
command. But, for this project I have a general ApplicationUser class representing all the users of my application. What if I have different categories of users. For example, I may have Teacher and Student entities and data representing both the entities will be different. How can I customize my application to store data for both the entities having all the features of ApplicationUser?
One way that I think is inheriting both the classes from ApplicationUser and then doing appropriate changes in IdentityConfig.csand defining Controllers for each of them. Is there any other efficient way of doing this?
What if I want to use the built-in authentication and authorization features but using database first workflow?
First, you want to know how to create "types" of users. The way you would do that is exactly how you expected: inherit from ApplicationUser. By default, this will result in a single "users" table with an additional Discriminator column. This column will store the class type that was persisted, i.e. "Teacher", "Student", or "ApplicationUser", and EF will utilize this information to new up the right class for each particular record.
One thing to note with this, though, is that you need to be aware of how UserManager works, namely that it's a generic class (UserManager<TUser>). The default AccountController implementation you have from the sample defines a UserManager property on the controller which is an instance of UserManager<ApplicationUser>. If you use this instance with something like Teacher, it will be upcast to ApplicationUser. In particular if you were to do something like UserManager.Create(teacher), it will actually save an ApplicationUser, instead (the Discriminator column's value will be "ApplicationUser", rather than "Teacher"). If you need to work with the derived user types, you'll need to create separate instances of UserManager<Teacher> and UserManager<Student> for that purpose.
Next, you want to know if you can use a "database first workflow". To answer that, we need to define exactly what that means. EF has what it calls "Database First" which employs EDMX to represent your database entities. This in particular is incompatible with Identity. However, despite the name, what EF calls "Code First", can work with an existing database just as well as create a new one. In other words, yes, you can use an existing database, if you prefer, but no you cannot use "Database First", in the EF-sense. For more information about using an existing database with Code First, see my post.
Related
Since #sys.airport only exists for the default English locale, I want to create a custom entity that emulates it for other locales.
From what I've read here, you can put subentity types into the value fields, say, the system entity #sys.geo-city:city and a custom entity #usr.iata-code:iata, and it will match either one or the other.
But I don't understand how you would tell Dialogflow which city and which IATA code go together, so that Dialogflow (ES) would know to send the complete object {"city":"Amsterdam", "iata": "AMS"} to the webhook after matching either "Amsterdam" or "AMS", as it does happen with #sys.airport.
Thanks for any input!
It will be difficult to create a custom entity that works just like #sys.airport. The #sys entities are special and can do somethings custom entities can't, for instance, pairing values together.
As you pointed out, you can put multiple entities together in one single entity by using Composite Entities, but the only thing this does is allow you to recognize two values made up from other #sys or custom entities in a single entity. It doesn't give you the option to create pairs between the values of the entities.
If you would want to create something like this, you would need some code that does a look up in a dictionary or list. So when "AMS" is matched, the code fills in the missing property "Amsterdam" or vice versa.
I am making a class diagram for Class/Course Registration where students have to first register their course then select their class schedules (timetable)
I am unsure if I can have CourseRegistration and ClassRegistration table like that. The reason why I made it like that is, a student can register for a course but doesnt register to a class directly. so they can wait few days and then only register. So I have to make sure the course registration is saved in the database.
Thank you for all the help
PS: pls don't mind my attributes, they're just a draft.
Your business logic for the registration process (register both for a course and a corresponding class) is too complicated. Normally, one would only register for a class, which would then imply taking the corresponding course.
Also, what does "ClassSchedule" stand for? Is an instance of a "ClassSchedule" a class meeting?
Since your model is supposed to define a design (of database tables and of, e.g., Java classes), each entity class should have an ID attribute defined, which is expressed in UML with the keyword "id" in curly braces appended to the attribute declaration. Having "ID" in the attribute names is not a formal declaration. Also, an ID attribute seems to be missing for ClassSchedule.
Yes, that's fine this way. You could alternatively use the association class notation like this:
Some side notes:
labeling associations is not that helpful except you are on a business level analysis. Rather use role names on either end where appropriate.
Edit I somehow overlooked that you're designing tables. So my previous comment
remove all the id attributes. Each object will have its unique id assigned by the runtime system. Use such an id only if it's of public meaning (e.g. a passport id or a student's registration number). And then use that specific name (e.g. passportId) rather than a <class>id.
goes just for basic class design. If you already have a (derived) table design you can just go with those ids.
I use jhipster and I would like to modify the User entity and add fields and relationships.
I use jhipster entity user and this command is not good.
How can I do it?
User is not a JHipster entity, the generator does not manage it. You must edit the code manually or add a related entity where you put additional fields, see doc: https://www.jhipster.tech/tips/022_tip_registering_user_with_additional_information.html
If you encounter a problem where you need to alter the User entity, Its recommend not doing that. Modifying this default entity might break your app depending on the nature of the changes.
Instead, there are other available solutions like:
creating an entity composed of the User entity
extending the User entity
Using composition
by using OneToOne relation like this
entity ApplicationUser {
additionalField Integer min(42) max(42)
}
relationship OneToOne {
ApplicationUser{internalUser} to User
}
Or
Using inheritance
This solution does the same thing as the previous one, but isn’t as straightforward as the first one because you need to:
create a new entity by hand,
adapt the code to make it use this new entity,
potentially manage yourself the database migration to persist this new entity (depending on the nature of the changes).
More info: https://www.jhipster.tech/user-entity/
I want to serialize an Entity Framework Self-Tracking Entities full object graph (parent + children in one to many relationships) into Json.
For serializing I use ServiceStack.JsonSerializer.
This is how my database looks like (for simplicity, I dropped all irrelevant fields):
I fetch a full profile graph in this way:
public Profile GetUserProfile(Guid userID)
{
using (var db = new AcmeEntities())
{
return db.Profiles.Include("ProfileImages").Single(p => p.UserId == userId);
}
}
The problem is that attempting to serialize it:
Profile profile = GetUserProfile(userId);
ServiceStack.JsonSerializer.SerializeToString(profile);
produces a StackOverflowException.
I believe that this is because EF provides an infinite model that screws the serializer up. That is, I can techincally call: profile.ProfileImages[0].Profile.ProfileImages[0].Profile ... and so on.
How can I "flatten" my EF object graph or otherwise prevent ServiceStack.JsonSerializer from running into stack overflow situation?
Note: I don't want to project my object into an anonymous type (like these suggestions) because that would introduce a very long and hard-to-maintain fragment of code).
You have conflicting concerns, the EF model is optimized for storing your data model in an RDBMS, and not for serialization - which is what role having separate DTOs would play. Otherwise your clients will be binded to your Database where every change on your data model has the potential to break your existing service clients.
With that said, the right thing to do would be to maintain separate DTOs that you map to which defines the desired shape (aka wireformat) that you want the models to look like from the outside world.
ServiceStack.Common includes built-in mapping functions (i.e. TranslateTo/PopulateFrom) that simplifies mapping entities to DTOs and vice-versa. Here's an example showing this:
https://groups.google.com/d/msg/servicestack/BF-egdVm3M8/0DXLIeDoVJEJ
The alternative is to decorate the fields you want to serialize on your Data Model with [DataContract] / [DataMember] fields. Any properties not attributed with [DataMember] wont be serialized - so you would use this to hide the cyclical references which are causing the StackOverflowException.
For the sake of my fellow StackOverflowers that get into this question, I'll explain what I eventually did:
In the case I described, you have to use the standard .NET serializer (rather than ServiceStack's): System.Web.Script.Serialization.JavaScriptSerializer. The reason is that you can decorate navigation properties you don't want the serializer to handle in a [ScriptIgnore] attribute.
By the way, you can still use ServiceStack.JsonSerializer for deserializing - it's faster than .NET's and you don't have the StackOverflowException issues I asked this question about.
The other problem is how to get the Self-Tracking Entities to decorate relevant navigation properties with [ScriptIgnore].
Explanation: Without [ScriptIgnore], serializing (using .NET Javascript serializer) will also raise an exception, about circular
references (similar to the issue that raises StackOverflowException in
ServiceStack). We need to eliminate the circularity, and this is done
using [ScriptIgnore].
So I edited the .TT file that came with ADO.NET Self-Tracking Entity Generator Template and set it to contain [ScriptIgnore] in relevant places (if someone will want the code diff, write me a comment). Some say that it's a bad practice to edit these "external", not-meant-to-be-edited files, but heck - it solves the problem, and it's the only way that doesn't force me to re-architect my whole application (use POCOs instead of STEs, use DTOs for everything etc.)
#mythz: I don't absolutely agree with your argue about using DTOs - see me comments to your answer. I really appreciate your enormous efforts building ServiceStack (all of the modules!) and making it free to use and open-source. I just encourage you to either respect [ScriptIgnore] attribute in your text serializers or come up with an attribute of yours. Else, even if one actually can use DTOs, they can't add navigation properties from a child object back to a parent one because they'll get a StackOverflowException.
I do mark your answer as "accepted" because after all, it helped me finding my way in this issue.
Be sure to Detach entity from ObjectContext before Serializing it.
I also used Newton JsonSerializer.
JsonConvert.SerializeObject(EntityObject, Formatting.Indented, new JsonSerializerSettings { PreserveReferencesHandling = PreserveReferencesHandling.Objects });
I am designing an application that will display dynamically-generated forms to the user who will then enter values into the form fields and submit those values for persistence. The form represents an employee evaluation.
One use case allows an administrator (from HR) to define the form fields. They should be able to create a new form, add/remove fields from a form and mark a form as 'deleted'.
The second use case is when a manager views the form and enters values into the form fields for a specific employee. They should be able to save the values at any time and recall the saved values when viewing the form again for the same employee.
Finally, when the manager is satisfied with the values they've entered for that employee, they can 'submit' the form data which persists the flattened data into the data warehouse for reporting purposes. When this is done, the 'working' copy of the data is removed so the form will display empty the next time they view it for that employee.
I am not concerned with the front-end at this point and working on the back-end service application that sits between the client and the data store. The application must provide a course-grained interface for all of the behavior required.
My question is how many aggregate roots do I actually have (and from that, how many repositories, etc)? Do I separate the form definition from the form data even though I need both when displaying the form to the user?
I see two main entities, 'EmployeeEvaluationSchema' and 'EmployeeEvaluation'. The 'EmployeeEvaluationSchema' entity would have a collection of 'FieldDefinition' value objects which would contain the properties that define a field, the most basic being the name of the field. The 'EmployeeEvaluation' entity would have a collection of 'FieldValue' value objects which contain the values for each field from the definition. In the simplest case, it would have a field name and value property. Next, the 'EmployeeEvaluation' could have a reference to 'EmployeeEvaluationSchema' to specify which definition the particular evaluation is based on. This can also be used to enforce the form definition in each evaluation. You would have two repositories - one for each entity. If you were to use an ORM such as NHibernate, then when you retrieve a 'EmployeeEvaluation' entity, the associated 'EmployeeEvaluationSchema' would also be retrieved even though there is a dedicated repository for it.
From your description it sounds like your objects don't have any behavior and are simple DTOs. If that is the case maybe you should not bother doing DDD. Can you imagine your entities without having getters? There are better ways to do CRUDish application than DDD. Again this is only valid if your "domain" does not have relevant behavior.