Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Large Application

Large Application

Scheduled Pinned Locked Moved The Lounge
csharpdatabasehelpquestionlearning
9 Posts 6 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N Offline
    N Offline
    Nicholas Naddaf
    wrote on last edited by
    #1

    Hi All I am involved now in rewriting and developing a large database application using .NET (C#), it has around 288 tables. is there any book that includes tips about developing large database application in C#? Please help Thanks

    M K 2 Replies Last reply
    0
    • N Nicholas Naddaf

      Hi All I am involved now in rewriting and developing a large database application using .NET (C#), it has around 288 tables. is there any book that includes tips about developing large database application in C#? Please help Thanks

      M Offline
      M Offline
      Marc Clifton
      wrote on last edited by
      #2

      Don't know of any in particlar, but here are Marc's helpful hints: use primary keys index judiciously for performance establish foreign key relationships now, not later use cascading deletes and updates look at LLBLGEN to with generating BO and DO layers hand code SQL queries for performance an absolute requirement--maintain clean separation between the data layer, business layer, and presentation layer. Marc Microsoft MVP, Visual C#

      1 Reply Last reply
      0
      • N Nicholas Naddaf

        Hi All I am involved now in rewriting and developing a large database application using .NET (C#), it has around 288 tables. is there any book that includes tips about developing large database application in C#? Please help Thanks

        K Offline
        K Offline
        Kant
        wrote on last edited by
        #3

        Depends upon the application. Is it WebForms based or WinForms based? Just like Marc suggested, I used LLBL Gen[^] for WebForms project. It's :cool:
        Promise only what you can do. And then deliver more than what you promised.
        This signature was created by "Code Project Quoter".

        M 1 Reply Last reply
        0
        • K Kant

          Depends upon the application. Is it WebForms based or WinForms based? Just like Marc suggested, I used LLBL Gen[^] for WebForms project. It's :cool:
          Promise only what you can do. And then deliver more than what you promised.
          This signature was created by "Code Project Quoter".

          M Offline
          M Offline
          Member 96
          wrote on last edited by
          #4

          Kant wrote: Just like Marc suggested, I used LLBL Gen[^] for WebForms project. It's I took a look at that, but I can't for the life of me see how it would work properly. I typically design my business objects *before* I design the database. Doing it the other way around (from data to b.l.) seems kind of old-fashioned isn't it?


          A cheap dominatrix offers bargain debasement.

          S M S 3 Replies Last reply
          0
          • M Member 96

            Kant wrote: Just like Marc suggested, I used LLBL Gen[^] for WebForms project. It's I took a look at that, but I can't for the life of me see how it would work properly. I typically design my business objects *before* I design the database. Doing it the other way around (from data to b.l.) seems kind of old-fashioned isn't it?


            A cheap dominatrix offers bargain debasement.

            S Offline
            S Offline
            Steve McLenithan
            wrote on last edited by
            #5

            John Cardinal wrote: but I can't for the life of me see how it would work properly I'll second that.

            // Steve McLenithan

            Cluelessnes:
               There are no stupid questions, but there are a lot of inquisitive idiots.

            1 Reply Last reply
            0
            • M Member 96

              Kant wrote: Just like Marc suggested, I used LLBL Gen[^] for WebForms project. It's I took a look at that, but I can't for the life of me see how it would work properly. I typically design my business objects *before* I design the database. Doing it the other way around (from data to b.l.) seems kind of old-fashioned isn't it?


              A cheap dominatrix offers bargain debasement.

              M Offline
              M Offline
              Marc Clifton
              wrote on last edited by
              #6

              John Cardinal wrote: typically design my business objects *before* I design the database. Doing it the other way around (from data to b.l.) seems kind of old-fashioned isn't it? Huh. For me, the two have pretty much no relation. And I usually design the schema first, but for me, the relevant thing is understanding the data and its relationships, and that comes first. A lot can be gleaned about the entire process (and the client's misconception of the process) by understanding that data and relationships first, IMO. The schema is optimized for data management. The BO's are optimized for the workflow/process. The UIO's (user interface objects, I guess) are optimized for the UI. Marc Microsoft MVP, Visual C#

              M 1 Reply Last reply
              0
              • M Member 96

                Kant wrote: Just like Marc suggested, I used LLBL Gen[^] for WebForms project. It's I took a look at that, but I can't for the life of me see how it would work properly. I typically design my business objects *before* I design the database. Doing it the other way around (from data to b.l.) seems kind of old-fashioned isn't it?


                A cheap dominatrix offers bargain debasement.

                S Offline
                S Offline
                Senkwe Chanda
                wrote on last edited by
                #7

                John Cardinal wrote: I typically design my business objects *before* I design the database Interesting, it would be nice to see what your business objects look like and the resulting DB structure. I'd like to hear more about your views on this if possible. Woke up this morning...and got myself a blog

                M 1 Reply Last reply
                0
                • M Marc Clifton

                  John Cardinal wrote: typically design my business objects *before* I design the database. Doing it the other way around (from data to b.l.) seems kind of old-fashioned isn't it? Huh. For me, the two have pretty much no relation. And I usually design the schema first, but for me, the relevant thing is understanding the data and its relationships, and that comes first. A lot can be gleaned about the entire process (and the client's misconception of the process) by understanding that data and relationships first, IMO. The schema is optimized for data management. The BO's are optimized for the workflow/process. The UIO's (user interface objects, I guess) are optimized for the UI. Marc Microsoft MVP, Visual C#

                  M Offline
                  M Offline
                  Member 96
                  wrote on last edited by
                  #8

                  Marc Clifton wrote: And I usually design the schema first, but for me, the relevant thing is understanding the data and its relationships, and that comes first. A lot can be gleaned about the entire process (and the client's misconception of the process) by understanding that data and relationships first, IMO Well I feel *exactly* the same way, but about the business objects, not the data. To me, the business objects are there to support what the users need to accomplish and from them ultimately will flow the data structure and design to support the business objects. I feel that this way is more user task oriented than doing it from the data upwards (as we always used to do back in the 20th;)). The end result for us has been much more user friendly applications that require less support and help because they operate exactly as the user expects them to. Actually it's not true that we design with the business objects first, what we actually do is write down a list of tasks that each class of user is going to want to accomplish when they run our program, the frequency and importance of each to each type of user. We then design the business objects to fulfill those tasks, mirroring the task from the users point of view and hiding the grisly technical hurdles inside the business object. Not surprisingly, the task the users want to accomplish seems simple to them but nearly always requires a much more complex technical solution under the hood than the old fashioned straightforward technical designs that we used to use based on how computers and databases work and *not* based on how people think. The data layer can be highly optimized, don't get me wrong, I just think it's there to support what the user wants to do ultimately, not the other way around. If you start with the data first then your really dictating a technical solution at the top level versus a user task oriented solution from the top down. A program with a really fast and efficient database layer results in a "technical" design rather than a user task oriented design can ultimately be a failure as a product for all the reasons that seem so good at the time to us programmers and database people. If you start with the database design, you end up creating data elements that mirror real world objects which seems good on the surface, but can break down when you get up to the user interface layer and realize that things that seemed logical at the time are not in any way a reflection of how the user actua

                  1 Reply Last reply
                  0
                  • S Senkwe Chanda

                    John Cardinal wrote: I typically design my business objects *before* I design the database Interesting, it would be nice to see what your business objects look like and the resulting DB structure. I'd like to hear more about your views on this if possible. Woke up this morning...and got myself a blog

                    M Offline
                    M Offline
                    Member 96
                    wrote on last edited by
                    #9

                    See my reply to Marc for more about how we go into this process in our shop: http://www.codeproject.com/lounge.asp?msg=751617#xx751617xx[^]


                    A cheap dominatrix offers bargain debasement.

                    1 Reply Last reply
                    0
                    Reply
                    • Reply as topic
                    Log in to reply
                    • Oldest to Newest
                    • Newest to Oldest
                    • Most Votes


                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • World
                    • Users
                    • Groups