need ideas in Web application architecture RRS feed

  • Question

  • hi everyone,

    I got a big problem in web desiging.

    I start my design with the database,coding design,and implementation.

    after completing all those things there is always a change in the database.so i need to change my code from top level hirarchy till the end.it increases my overall timing in the coding and redesiging.change in db is reflected in the logic results in overall change of the code.

    is there any architectural design which directly maps my webform fields with the database table and colums. i need to change only the configration files alone instead of the code.

    you can take a simple example medical record maintance.

    which holds the details of patients,doctor etc.At one point time the entire database schema changes.

    thanks in advance






    Tuesday, December 5, 2006 2:21 PM

All replies

  • This is a pretty common problem in software development. If you know going into the project that you will face Problem X sooner or later, it's good to tackle it in the design.

    There are a couple of ways people deal with this. InfoPath is good if you have data fields that are very prone to change. If your UI is mostly static, however, and you are just talking about the inevitable "I added a column or changed its datatype" dilemma, you should look at typed datasets.

    Datasets are typed by default in .NET 2.0. When you add a new DataSet file it's going to include an xsd as well as a codebehind file implementing a proxy object with fields that represent the database columns.

    You can load the dataset schema from any SQL Server table in your server explorer. You can also refresh these schemas, telling them to update themselves to the current schema of the database.

    When you say there is a change in DB - If you are talking about a full restructuring of your database (complete data model overhauls etc). then I don't think you can really expect to get away with making easy changes without addressing it at an architectural level. Even if you had a configuration section handler that allowed you to map web forms to fields, you'd still have to update the web.config anyway to say "Table1.Column1" etc. So it seems like most of us just use datasets to accomplish this task at a simple level.

    If you are set on being able to map web form fields to a database, you'll need to build a custom data access layer. To implement this, you need to have (at a minimum):

    - a configuration section in the web.config for your field mappings
    - a configuration section handler to actually apply the mappings
    - a data access object that has the ability to index into the underlying dataset using the field mappings you specified in the web.config.

    I have seen such a thing built in the field before and it turned out looking a lot like InfoPath. You might consider looking at that tool since it is built to solve that class of problems.

    Tuesday, December 5, 2006 3:57 PM
  • Thanks Dan,

    Even my idead matches with your idea.i missed infopath.i will take look in to info path.

    thanks for your valueable ideas.i will keep posting...



    Wednesday, December 6, 2006 4:25 AM
  • Have u tried .. LINQ formerly know as ObjectSpaces.

    you can start from here



    vikas goyal

    Wednesday, December 6, 2006 7:14 AM
  • With the risk of someone jumping on top of me, if you can't solve the problem, remove it.

    What I mean is, if a change in the database schema is going to be a problem, don't use a database schema.

    I've seen several solutions where the schema itself is stored in the database (in fact, in most databases it's already stored there, but you might have different requirements). You could use a datamodel to store a schema, or you could simply store XML in a text field and use an XSD to define the schema and an XSLT to define the user interface. These are all things you can do relatively easy (altough they may seem hard at the moment).

    Wednesday, December 6, 2006 2:19 PM