locked
How to prevent affect of changing column name of db in our layers ? RRS feed

  • Question

  • User-541930774 posted

    Hi ,

    Sorry I'm beginner  , In my architecture i use Objects instead of dataset or TypedDataset .

    I've read one of main goal of multi tier programming is for improving maintanability and extensibility , But  all the time i have this worry  that if i change a column name in db i have to change the name of equivalent property in Buissiness Entity class and in every where that i used that property like  DAL or every where else .

    What do you suggest me , Or it's better ask you what do you professinals do ?


    Thursday, December 24, 2009 3:27 AM

Answers

  • User541108374 posted

    Hi,

    refactoring's a job regularly done. Resharper from JetBrains is a good assistant for this.

    On the other hand we use an ORM mappers (Linq to Sql) which generates the classes for us when we, after changing a table, drop it again on the designer of the dbml. Besides that we have custom written datatypes which closely resemble our tables but we do fill them up in the DAL layer by L2S statements. Whenever some database change happens we only need to adapt our DAL layer while the other layers (business, service, UI, ...) mostly stay the same. If it's a big change of naming convention we adapt the datatype also and use Resharper to change for the refactoring.

    Also we use custom objects for transportation of the datatypes instead of passing in every "column" in the method signature. When we need to refactor then we don't have to change all these method parameters also.

    Grz, Kris.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, December 24, 2009 3:41 AM

All replies

  • User541108374 posted

    Hi,

    refactoring's a job regularly done. Resharper from JetBrains is a good assistant for this.

    On the other hand we use an ORM mappers (Linq to Sql) which generates the classes for us when we, after changing a table, drop it again on the designer of the dbml. Besides that we have custom written datatypes which closely resemble our tables but we do fill them up in the DAL layer by L2S statements. Whenever some database change happens we only need to adapt our DAL layer while the other layers (business, service, UI, ...) mostly stay the same. If it's a big change of naming convention we adapt the datatype also and use Resharper to change for the refactoring.

    Also we use custom objects for transportation of the datatypes instead of passing in every "column" in the method signature. When we need to refactor then we don't have to change all these method parameters also.

    Grz, Kris.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, December 24, 2009 3:41 AM
  • User-690506545 posted

    Don't change the name of the column?

    Adding or removing columns would need a change everywhere, because presumably you are adding it or removing it for a reason.

    If you HAVE to rename it, then the options are:

    1. Rename in the table, adjust the views/stored procs accordingly, but expose the same interface (with the old name) back to your datalayer.  If the views/stored procs have to change, then change the datalayer only and map the old name to the new name.

    2. Rename it in the table/view/storedprocs, then refactor your code to deal with the name change.

    Maintainability doesn't mean that you don't HAVE to maintain it, it just means it's easier to maintain because it's easier to test your changes, as each area is testable as a stand-alone unit.

    Thursday, December 24, 2009 3:48 AM
  • User-541930774 posted

    Thank you both , Usefull .

    Do you mind if explain a bit more about this(Any sample code) ?

    Besides that we have custom written datatypes which closely resemble our tables but we do fill them up in the DAL layer by L2S statements. Whenever some database change happens we only need to adapt our DAL layer while the other layers (business, service, UI, ...) mostly stay the same.

    Thursday, December 24, 2009 4:59 AM
  • User541108374 posted

    Hi,

    the code itself is classified but it boils down to passing 1 object through all layers as input parameters, datacontracts, which have public properties of a certain (data)type and towards the DAL pass in more concrete input parameters. The return value is also a datacontract which holds public properties of a (data)type and in the DAL/repository we fill it up like for example:

    (from a in dc.Address
    where a.Id = somepassedinId
    select new AddressDataType
            {
                StreetName = a.Street,
                City = a.City
            }).ToList();


     

    Whenever we would rename the Street column in the Address table we could still use the StreetName in the other layers without change and would only have to alter our L2S statement to fill up the correct data for StreetName.

    Grz, Kris.

    Thursday, December 24, 2009 5:10 AM