locked
Transform data from Data layer to Business layer RRS feed

  • Question

  • Hi. Suppose that I have to fill some business objects with data from a database, but that I have to transform the data from the database because of impedance mismatch. I would like to know if this type of code should be considered part of the Data layer or part of the Business layer. More in general, when I can not avoid a problem like that, I have the impression that it is not possible to persist the data changed by the user interface without coding the opposite transformation, quite straightforward, but also that this problem is independent from the data model I am using, may be less straightforward. Do you know if there is a best practice when it is not possible to avoid the transformation? Thanks.




    • Edited by speculor Friday, January 4, 2013 10:09 AM
    Friday, January 4, 2013 10:02 AM

Answers

  • Speculor, 

    There are ton's of best practices. But all are made of the known practice from somebody at that time.

    Be aware that terms of Business objects are fine marketing slogans, but the explanation of that is with every brand different. I've never recognized an overall commitment of what is a Business class so that I also don't describe here. Mainly it should contain all the Business related aspects of an application, but some do than the data part in that. 

    However, at least split your code in layers in windows (projects) makes it easier to maintain with more persons and to reuse some parts of that. I would not make any solution (that is why it is called solution) from one project. 

    Now the practical part of this. How to do this. 

    First of all take care not to create any real data code inside an UI class, then create the data classes in your Data Project (layer).

    You create layers simply by "adding" to an existing project a new project.

    Your last statement, avoid transformation, for that has Microsoft created the Ententy framework.

     http://msdn.microsoft.com/en-us/data/ef.aspx


    Success
    Cor


    • Edited by Cor Ligthert Friday, January 4, 2013 10:34 AM mistyped
    • Marked as answer by Youen Zen Wednesday, January 16, 2013 10:20 AM
    Friday, January 4, 2013 10:33 AM
  • Speculor,

    I only can speak from what experience has taught me. 

    Don't make it yourself to difficult, programmers live from the new inventions which have taken place in time. You can normalize a database until the last element and then see that your database is busy only retrieving elements. You can try to create classes which fits for everything and then see that 99% is unused.

    However, you don't know what is the new invention tomorrow which will make all your previous work useless.

    Therefore I've always followed the 20-80 rule. Try to do the best for that what fits in 80% of the cases and do that last needed 20% at the moment it is needed. You will see that otherwise that 20% takes 80% of your time.

    :-)


    Success
    Cor


    • Edited by Cor Ligthert Friday, January 4, 2013 11:22 AM
    • Marked as answer by Youen Zen Wednesday, January 16, 2013 10:20 AM
    Friday, January 4, 2013 11:21 AM

All replies

  • Speculor, 

    There are ton's of best practices. But all are made of the known practice from somebody at that time.

    Be aware that terms of Business objects are fine marketing slogans, but the explanation of that is with every brand different. I've never recognized an overall commitment of what is a Business class so that I also don't describe here. Mainly it should contain all the Business related aspects of an application, but some do than the data part in that. 

    However, at least split your code in layers in windows (projects) makes it easier to maintain with more persons and to reuse some parts of that. I would not make any solution (that is why it is called solution) from one project. 

    Now the practical part of this. How to do this. 

    First of all take care not to create any real data code inside an UI class, then create the data classes in your Data Project (layer).

    You create layers simply by "adding" to an existing project a new project.

    Your last statement, avoid transformation, for that has Microsoft created the Ententy framework.

     http://msdn.microsoft.com/en-us/data/ef.aspx


    Success
    Cor


    • Edited by Cor Ligthert Friday, January 4, 2013 10:34 AM mistyped
    • Marked as answer by Youen Zen Wednesday, January 16, 2013 10:20 AM
    Friday, January 4, 2013 10:33 AM
  • Hi and thanks for your answer. I know that EF was created in order to handle the impedance mismatch. But I can not believe that I can use EF in order to avoid the impedance mismatch in all scenarios. Are you telling me that if I need that transformation, it is very likely that I am designing the Data layer in the wrong way? Ok, may be that I can design the Data layer in order to avoid the impedance mismatch in a particular user interface, but that designing the Data layer in that way I meet other problems and a less clean solution when I have to deal with other tasks. Which is the priority? Suppose that I have definitely decided to design the Data layer in a particular way because I think that that design is the best for most of the tasks. Ok, I meet an impedance mismatch in a particular user interface. What should I do? Thinking and thinking to a solution which solves this problem without creating other problems in the tasks for which I had decided the first model (does it exist?), or continue with my first model because an impedance mismatch in a particular user interface is not the end of the world? I mean, does meeting an impedance mismatch in a solution mean that I am wrong somewhere? I hope not. Really, what do you think about? It is important for me because I am realizing that I am never sure about the strategy that I should take. Thanks.

    Friday, January 4, 2013 10:56 AM
  • Speculor,

    I only can speak from what experience has taught me. 

    Don't make it yourself to difficult, programmers live from the new inventions which have taken place in time. You can normalize a database until the last element and then see that your database is busy only retrieving elements. You can try to create classes which fits for everything and then see that 99% is unused.

    However, you don't know what is the new invention tomorrow which will make all your previous work useless.

    Therefore I've always followed the 20-80 rule. Try to do the best for that what fits in 80% of the cases and do that last needed 20% at the moment it is needed. You will see that otherwise that 20% takes 80% of your time.

    :-)


    Success
    Cor


    • Edited by Cor Ligthert Friday, January 4, 2013 11:22 AM
    • Marked as answer by Youen Zen Wednesday, January 16, 2013 10:20 AM
    Friday, January 4, 2013 11:21 AM
  • Ok. It seems a good starting point. I am always looking for the perfect solution, I undestand that most of the time it is useless, also because it is very likely that it does not exist. I have to consider the 20-80 rule, even if it is terrible that 20% of the solution will take 80% of the time. Thank you very much for your tip. I must remember it. 

    Friday, January 4, 2013 12:04 PM
  • Your question is rather conceptual in nature and could use a specific example. Otherwise, it's not VB related and may be more specific to ADO.NET or EF, at least on the client side.

    http://social.msdn.microsoft.com/Forums/en-US/category/dataplatformdev


    Paul ~~~~ Microsoft MVP (Visual Basic)

    Friday, January 4, 2013 1:48 PM
  • You are right. Sorry for that and thanks for the link.

    Friday, January 4, 2013 2:18 PM