I am trying to reverse engineer a SQL Server database to an Entity Framework Data Model (version 6.0). The classes are generated fine, but required fields are not decorated as such. As a result the validation is not working (in an MVC 5 web application).
Is there a way to make the model generate these attributes automatically or do I have to manually write meta data classes for all my entities?
Speaking to your question, What are your assumptions for required fields? Do you mean non-nullable?
EF should make any field that is marked as not null as either a non-nullable value type (int, decimal, bool, etc.) or it will make fields required via xml validation. EF doesn't typically add attributes.
MVC will automatically make any value types required, no attribute is required. For strings or other possible nullable types, then you will either need "buddy classes" to add the attributes you need, or you use view models.
Related
Is it possible to have a OneToManyAssociationField as entity extension on for example ProductManufacturer without the ReferenceVersionField in my related custom entity?
If this is not possible, is it possible for the reference version field to have a custom name (so not product_manufacturer_version_id) On first sight, this also does not seem possible.
About the error
I am currently getting the following error when trying to search for manufacturers using $criteria->addAssociation('myCustomEntity'):
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'product_manufacturer.myCustomEntity.product_manufacturer_version_id' in 'field list'
About the big picture
The use case is similar to the SeoUrl entity where there is a ‘foreign_key’ field which can have a relation to multiple entity types. My entity has not associations, but the other entities are extended to have an association to my entity. Just like the SeoUrl.
However, the DAL creates a query which uses the ‘product_manufacturer_version_id’ field, which does not exist on my custom entity…
Is it possible to have a OneToManyAssociationField as entity extension on for example ProductManufacturer without the ReferenceVersionField in my related custom entity?
No, you must set a ReferenceVersionField when adding associations to the definition of a versionized entity. This is too deeply rooted in the basic principles of the data abstraction layer to work around.
If this is not possible, is it possible for the reference version field to have a custom name (so not product_manufacturer_version_id) On first sight, this also does not seem possible.
You can change the storage name of the field. That is the name of the corresponding column within your database table. When you instantiate ReferenceVersionField you can use the second, optional argument to provide the storage name:
public function __construct(string $definition, ?string $storageName = null)
The storage name should be provided in snake case. The name of the object property for the field will then be derived from the storage name and converted to camel case. So given you provide my_version_custom_id for the storage name, the object property of the entity will be myVersionCustomId.
Your entity may have multiple associations to different entities, but if those entities are versionized your foreign key constraint has to be a combination of columns for both the foreign primary key as well as the foreign version id.
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.
we're using Automapper (http://automapper.codeplex.com/) to map between entities and dto's. We have a situation where one property on an entity corresponds to three different properties on the dto, and we need to write some custom logic to do the mapping. Anyone know how we can do that? (We need to map both ways, from entity and from dto).
I notice that AutoMapper supports custom resolvers to do custom mapping logic, but as far as I can tell from the documentation, they only allow you to map a single property to another single property.
Thx
You can create a custom type converter. It allows you to define a converter for an entire type, not just a single property.
I'm trying to build a custom HTML helper for MVC.NET that would allow me to render object entities (Model Objects) as HTML forms. So I decided to do it using custom attributes such as html input type, readonly flag, css classes, etc. Similar in a way to LINQ Mapping attributes that set database related bindings for Table and Column. So I did write a custom attribute class, applied it to the same entities that I store in the database, but when I retrieve an entity class from a database to display in a View, all of my custom attributes are gone. Is there a way to retain my custom attributes, AFTER they come back from a database?
I am creating a form in JSF to save a new entity bean. I binding the properties of the new entity to input elements use the value property e.g. , where backing bean is JSF managed mean and newEntity is filed of the backing bean whcih contains a new instance of my entity. For properties which are value types (like numbers), the input fields will be populated with default values (e.g. 0). I want all the fields to be blank initially and saved back the new entity instance when the page is submitted. I suppose I could make all the properties null able by using types such as Integer but the values aren't null able in the database and it doesn't seem right that the requirements of my user interface should dictate the form of by business layer. I am looking at this the wrong way?
I assume that if the fields aren't nullable, then they are required. If you put required="true" on the field, then validation should fail before the value can be assigned. This means it won't try to assign null values to your attribute. You may have to write a custom validator to do this for some types of fields.
Alternatively, you can write a converter. This converter would have to convert empty values to some predetermined constant such as -1 that you know is invalid. And vice versa, it would have to convert -1 to empty value for display. Then you have to deal with all the invalid values before sending it to the business layer.
I've used both of these methods, but I much prefer the first. If the fields are not required, they should be nullable in the business layer.