none
Technology to choose RRS feed

  • Question

  • Hi all,

    I'd like to ask you for some advice, am not a beginner programmer but this is the first serious project on WinForms, the main problem is that some part of the project is already written by someone else (not very good in programming :)) and this part is already in use and I have to add other new modules to what's already done; and this ready part is written considering almost no good programming practices (raw sql in C#, no good architecture etc.)

    I'm good in nHibernate and Entity Framework but as I see I won't be able to integrate new modules built on some ORM technology (at least it would be not so easy), but I don't want to mix up raw sql with C# code either :)

    Yes, I could call stored procedures from the database but maybe there are some better solutions.

    so, what would you suggest? Which strategy or technology should I choose?

    Thank you

    • Moved by Mike Dos Zhang Wednesday, March 9, 2011 9:09 AM architecture problem (From:Windows Forms General)
    Monday, March 7, 2011 9:39 PM

Answers

  • Hi all,

    thanks a lot for support and suggestions,

    I decided to choose Entity Framework, EF 4.1 gave me ability to migrate from the old code quite easily using POCOs, at extremely problematic points I left standard ADO.NET approach but moved all the SQL from code to the database stored procedures

     

     Regards


    Accuracy VS Precision
    Wednesday, June 15, 2011 11:57 AM

All replies

  • Not sure why you pick this forum instead of the Architecture forum or the ADO.Net forums. Do you imply you need some help in Windows Forms GUI as well?

    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Monday, March 7, 2011 10:07 PM
  • Hi zautashvili,

     

    Base on your description, the project will be added other new modules.

     

    If the new module is isolated with others, you can use the new technology such as nHibernat and Entity Framework. So you don’t mix up raw sql with c#.

     

    If you have to use the table before building, you can continue to use a raw sql with c#.

    I think the raw sql is important to all programmers. Even though the O/R mapping technology is very good and convenience, the sql is fundamental.

     

    You also can use the Shored procedure in the new module so that you can use a few sql with c#.

     

    Sincerely,

    Daniel Wang

    Tuesday, March 8, 2011 5:18 AM
  • Hi zautashvili,

    The experts here will give you more expert help on this kind question.

    Best wishes,


    Mike [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, March 9, 2011 9:10 AM
  • "It depends"

    You'll have to provide a little more information about the project under question. The correct answer could be embedded SQL in c# and no ORM.

     


    http://pauliom.wordpress.com
    Wednesday, March 9, 2011 4:28 PM
  • Depending on the scale of your project, the cost of migrating with existing C# module to non-MS framework and adapting yourself to C# will vary. From my opinion, if your part is not very big(1K lines or above), you should consider developing in C#. It's easy to use and will save lots of pain Google for solutions why the migration didn't work....

    abercrombie & fitch is a popular brand to the teenage guys and girls. Almost every mall in the states have this brand. A & F (short for abercrombie and fitch) is the “trend-setter” for teenagers. They sell almost everything, such as Flip Flops, Totes, Tops, Bottoms, Perfume, swimwear, scarves…
    Tuesday, March 15, 2011 8:40 AM
  • Ok... going to make a radical suggestion. This is way out there man.

    How about you fix the existing code base. Or put another way ... refactor the bad practises into good practises... refactor out the direct SQL into a ORM... break those tightly coupled dependencies best you can, get the mofo system under test.

     

    You know that phrase developers hang on to .... if the code isn't broken then don't fix it.... well if you say that about any piece of code then guess what?

    the code is broken!

     

    Set up an eco system of source control and CI, slowly get that system under test (or the parts you need to work with) and fix it while fitting in the new stuff.

     

    If your company is employing at the moment tell them to get in touch.

     


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Tuesday, March 15, 2011 2:11 PM
  • I have to disagree with Derek, well potentially. You need to explain the problem before even considering technological solutions such as ORMs. E.g. if the problem is; show all countries in the tombstoned read only Country table, then an ORM is a massive overkill. Drag and drop it onto a data set, job done. Now is the problem really that simplistic, I don't know!

     


    http://pauliom.wordpress.com
    Tuesday, March 15, 2011 2:58 PM
  • I have to disagree with Derek, well potentially. You need to explain the problem before even considering technological solutions such as ORMs. E.g. if the problem is; show all countries in the tombstoned read only Country table, then an ORM is a massive overkill. Drag and drop it onto a data set, job done. Now is the problem really that simplistic, I don't know!

     


    http://pauliom.wordpress.com


    Oi!! how dare... Yeah ok. Actually... no.  :)

    Technical debt always costs more in the long run. If your thinking of keeping the cost down then fix the code base. Code is the companies investment, companies that forget that will pay more for their investment while receiving little in return. 

    Anyway that is a seperate discussion.

    As to what technology to use pkr2000 is right the original post concentrated on all that was wrong in the solution, the past, and not on what was needed to be done.


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Tuesday, March 15, 2011 3:13 PM
  • I'm inclined to agree with Paul... and definitely Derek's last paragraph.

    Often you might want to rewrite swathes of a project but it's not really worth it.

    Sometimes, a project is that bad that refactoring it is justifiable.

    I think completely rewriting a project using TDD and replacing all data access with nH/EF is likely to be a hard thing to justify.   

    I'm going to take a wild guess here - maybe the client doesn't have a huge development department and isn't used to development projects.  Maybe it's a smallish sort of company with a limited budget.

    In my experience.  Most "rewrite" discussions in such an environment involve the person you're trying to convince saying "But it works" every time you try and explain why the system is bad.

    Wednesday, March 16, 2011 10:15 AM
  • It's the boy scout rule. Leave the campsite better than you found it.

    It doesn't say how much better. Could just be a tiny little bit better but if everyone who touched that code base made it just a tiny little bit better then over time the code will gradually become most excellent.

    If the original code.... I'm away off on one again.....

    Full system rewrites to fix bad code or design are generally never a good idea.

     

    9           GOTO 20

    10         Although have yous ever seen FORTRAN code that was written in the 70s?

    15         GOTO 25

    20         GOTO 10

    25         Because I have!


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Wednesday, March 16, 2011 11:44 AM
  • Improving things is good.  Can't argue with that.  If the code is completely awful then it's obvious that it ought to be "fixed".  Often it's not quite so clear cut though. 

    Do you paint?

    I mean on canvas.

    There's no particular way to tell a painting is finished.  There's a tendency to continue painting and painting forever.  You can always see something to improve. The professional artist' advice is to get the painting "pretty much OK" then leave it alone.  Maybe come back in a week but limit your changes to 30 minutes painting.  Which is where the metaphor probably breaks, but anyhow.  If you were an artist and someone gave you another artist's work to "finish" then the chances are you'd be happier just starting anew.  Every artist has a different style. 

    I think looking at other people's code is rather like that.

    I can almost always see something I think I could improve.  Make it simpler, more elegant, more complex, more.... more like I would have written it.  Because the way I write code is obviously better. Obviously ;^)

    Is converting everything to use EF really going to improve the bits that's already written?

    and

    Is that improvement going to be sufficient to justify the work?

    Wednesday, March 16, 2011 12:54 PM
  • Hi all,

    thanks a lot for support and suggestions,

    I decided to choose Entity Framework, EF 4.1 gave me ability to migrate from the old code quite easily using POCOs, at extremely problematic points I left standard ADO.NET approach but moved all the SQL from code to the database stored procedures

     

     Regards


    Accuracy VS Precision
    Wednesday, June 15, 2011 11:57 AM