Large Application
-
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
-
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
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#
-
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
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". -
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".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. -
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.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. -
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.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#
-
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.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
-
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#
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
-
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