Home/ Questions/Q 1022661
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T11:29:57+00:00

I am designing an application for a library. Not a large scale library, but

  • 0

I am designing an application for a library. Not a large scale library, but a very small scale library where my primary task is to just keep information about the books. But this library application should be able to adapt to any professional’s private library. For an example, for a lawyer, apart from the basic information about the book (title, author, publisher etc), there maybe other special fields that is associated with a book (Case Number, Court Number etc). A doctor may have some other special attributes for a book. Same goes for other professions.

So I am going to use an SQL Server CE database and I am hoping to have a BOOK table with the usual attributes and on demand ALTER the table to suit the special needs (add more columns).

But my worry is generating the GUI dynamically to support the new attributes.

Are there any approaches to tackle the dynamic GUI generation?

I am not asking for complete code (which obviously I wont get), but if you do have any coding to support the approach, please be kind enough to post it 🙂

Is there anything I should know about the pros, cons, dead ends, cautions or warnings etc?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    On the data model side that @devnull picked up, you are describing a custom fields implementation and @devnull is describing the EAV model.

    There’s a good stackoverflow article that covers design patterns for custom fields in an application:

    What are design patterns to support custom fields in an application?

    The data model choice and the UI generation are tightly linked, so you can’t really answer the UI generation question until you decide on your data model/custom field pattern. My initial reaction was the same as @devnull’s on the alter approach, but there really is no great solution.

    You can reduce a lot of complexity if you have a superset of all possible fields and allow the user to enable/disable the ones that are appropriate to their application domain. I’ve done several implementations of custom fields in an application with very smart people and it’s always hard. If you understand the application domain well enough you can stay away from the uber-flexible architectures and save yourself a lot of grief.

    Note that an important consideration is whether they will need to query on the custom fields. It’s much easier if you don’t have to support general querying. You just slot userdate1, usern, etc. and provide a metadata table for labels.

    • 0