I have a requirement from a client to give them the option to add custom fields to a program i am going to write for them. The custom fields will be on a per/poco basis. What is the best way of handling custom properties like this. I am going to use SQL Server and ASP.NET MVC4.
Just need a starting point..
thanks in advance.
The way we handle this where I work is storing the information in a database table. We store the field name, the value, and some identifier for which object it belongs to. Sometimes we have an additional table stores the specific list of available values.
When it's pulled out of the db, we place it in a dictionary list. If you set up some conventions then it's not too bad building validation for the fields. I.E. any field name with "phone" in the name gets validated as a phone number.
Related
I am in phase of designing architecture of my web application. I want to work with asp.net mvc5 and oracle database at back end.
One basic requirement of my project is that the application's admin users can add/remove Form Fields. I want to physically add/remove columns in my database tables at run time (not design time).
How can I achieve it in mvc and how the models can be updated dynamically at run time?
Should I use some ORM or how I design data access layer for that?
I just need suggestions and hints for the architecture design approaches.
Instead of physically adding and removing the fields at runtime you can try the following table structure
Field Name Field Type
CustomField1Name Nvarchar(256)
CustomField1Value Nvarchar(Max)
CustomField1IsVisible Bool
CustomField1FieldType Nvarchar(32) [char/numeric/bool etc]
CustomField1Required Bool
CustomField2Name Nvarchar(256)
CustomField2Value Nvarchar(Max)
CustomField2IsVisible Bool
CustomField2FieldType Nvarchar(32)
CustomField2Required Bool
If you need any more field specific information like custom validation you can add here.
Repeat this for how many custom fields you want . Due to this design, in run time there will be no structure changes in DB level. All changes you can do in coding level.
Entity attribute value pattern is one way to go. In my opinion this becomes an anti-pattern if overused. This has some shortcomings such as storing every value as a string. You might find it hard to parse "true+" as a bool. You could also do this in a weakly typed fashion or weakly typed datasets. If you want to go this route you would actually be creating columns. Do not give users rights to create columns, give them rights to execute a proc that creates columns.
I'm new to Core Data and I got stuck at this part of my xCode project.
I have created a core data entity "Person" and this entity has the following attributes:
name;
age;
birthday;
address;
and this attributes are getting displayed in a tableview. So far so good.
My problem is that I want the table to have an "Add Field" or "Add Row" cell so when the user wants to add more information in addition to these already created attributes he just clicks the cell and chooses the field name and type.
For example if he wants the person's "phone number" in the detail view of the table he names the new field "phone number" and chooses its type "number". Then he has an extra field where he can add the person's phone number.
How can I do this in core data? Is there a way for a user to manually add a new attribute to an entity and choosing its format? What is the best approach? Thanks.
You can't do exactly what you want with Core Data. Core Data can't change structure except if you make a new version of your design, but you do that in xcode.
But you can easily add another table called f.ex. information, which links to the person single connection and has the person linking back many to the information table.
This way, you can add as many fields and values as you want, of course all the extra fields you add would follow the same person, so if you want to use cellPhone field, you must add that to all.
I would recommend that you use direct SQL, and don't use Core Data. Core Data is not a database, it is an object store, and when you get better at iOS development, you will understand the difference, it is much bigger than you might think at first.
There is an excellent high level library for SQLite, called FMDB, you can find it on github here : https://github.com/ccgus/fmdb
Here you can do direct SQL queries like "Alter Table" and more on the fly, though what you are after isn't very simple, it could be real fun project to do.
Good luck with this.
I don't think this is directly possible in Core Data because its purpose is object persistence and you can't add new properties to objects dynamically. It could be faked to some degree using a to-many relationship to an "extra property" entity that had name, value (as string), and data type fields.
I believe your best option would be using SQLite in order to modify the table structure on the fly. (http://www.sqlite.org/lang_altertable.html)
My last company did something like this, but its not trivial. I don't have access to the code so this is more or less going to be from memory.
you provide transformable property in your entity (which will be a dictionary)
the model object has to provide the getter and setter for this that in turn drive the primitive methods to set/get an attribute
you provide a getter/setter along the lines of -objectForKey and -setObject forKey, which read and write values
when you are told to 'fault', you update the dictionary in the entity
In summary, maintain a dictionary of key value pairs. Perhaps you maintain a shadow dictionary that gets initialized and updated as needed. Its been around 4 years since I last saw this code so a little fuzzy on it. But you should get the idea. It was like magic - you can arbitrarily set any key/value pair (assuming string keys and NSCoding compliant values), and can always ask for the keys by asking the dictionary for its current set of keys.
I'm trying to implement a very granular security module in an ASP.NET MVC 3 app where only certain users can edit certain columns on records in a table. I can imagine that the update SQL statement's list of columns would only include the columns that the user had the right to change. The thing is, I'm planning to use an ORM like NHibernate. I'm wondering if NHibernate provides a way to determine at runtime which properties of a model should be part of an Update. Or is my only option to, on the POST method, get the model again from the database, set only the properties that the user is allowed to set then finally Save the model. Also, is this a good way to handle my requirement of of granular security?
Would dynamic-update and dynamic-insert be enough?
dynamic-update (optional, defaults to false): Specifies that UPDATE SQL should be generated at runtime and contain only those columns whose values have changed.
dynamic-insert (optional, defaults to false): Specifies that INSERT SQL should be generated at runtime and contain only the columns whose values are not null.
Otherwise it might be possible with events or interceptors, but I've never used them so I don't know exactly.
I want to display an editor for a type User. User contains a field Address of type Address. I made an editor template for the type Address so that it is reusable.
I don't want the field Address to be required for creating a user. But some fields are required for Address, for example country, state etc.
I want to validate Address if I receive any data for it, if I don't receive anything, then I don't want to return any validation error to the UI for Address. I would return only validation errors for User then.
What would be the best way to do this?
Thanks,
I used some code from Simon J Ince of Microsoft. He has it here on his blog. It also has client side validation which is also nice. It has a RequiredIf attribute that only makes a field required if another field has a certain value. Just being able to see how he implemented it helped me figure out how to do some of this stuff by myself and I even retrofitted it to allow multiple values.
You might want to look into a Custom Model Binder for your User type. That way you can choose to override the validation of the Address item inside a User.
I have found that more complex custom validation is easier with FluentValidation. The documentation provided is very helpful, and you will be able to achieve your validation goal with this open source validator.
I have a customer requirement to export the checks written in QuickBooks into a specific format because their bank allows fraud prevention by uploading a file and they verify the name on the check against what you give them before clearing it.
I looked at the QuickBooks SDK (we use the XML to communicate in general) and It references a field on the check called PayeeEntityRef with a FullName property, but typically in QuickBooks that data structure would indicate what the entity is called, not what appears on the check (Vendors have a NameOnCheck property, for example, which can be something other than their name).
Without coding up multiple test cases to demonstrate QuickBooks behavior here, does anyone have experience with getting the name as it was printed on the check? What is the best way to do it?
It's somewhat possible to get what you are wanting, but there are going to be some hiccups that you'll need to let you client know about. The main problem being that there's no way to retrieve the actual name printed on the check.
You would first need to query for the Checks/Bill Payment - Checks for the bank account. Then, using the PayeeEntityRef (I would use the ListID component) figure out which "List" the entity is on; Customer, Vendor, Employee, or Other. I don't know of any way to tell which list the PayeeEntityRef is from other than doing a query for each of the lists.
If the PayeeEntityRef is a Vendor or Employee, then you can retrieve the NameOnCheck value. The only thing you would need to keep in mind is that if the NameOnCheck has been modified AFTER the check was printed, the names will not match.
If the PayeeEntityRef is a Customer or Other name, then you have to do a little bit more. The value that QuickBooks uses for the printed name is based on what fields are filled out for the customer record. It first will use the CompanyName field if it is not null. Next, it will try to use the First/Middle/LastName fields, if they are not null. Finally, it will use the Name field as a last resort. Keep in mind that this is not the FullName field, just the Name field.
I haven't tested this with an "Other" name, as I have my clients try not to use that list, but I would imagine it's similar to how Customers work.