how do you normally structure your source code

DickCappels

Joined Aug 21, 2008
10,153
Along with names other people can understand and comments that describe the function, something I have been doing for the last several years is commenting my code and in some cases, writing a comment that explains what a routine is supposed to do and what is affected.

This habit came about after re-using code written a decade or more earlier and then having to reverse engineer the old code, which sometimes is more difficult than writing it again from scratch.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
Along with names other people can understand and comments that describe the function, something I have been doing for the last several years is commenting my code and in some cases, writing a comment that explains what a routine is supposed to do and what is affected.

This habit came about after re-using code written a decade or more earlier and then having to reverse engineer the old code, which sometimes is more difficult than writing it again from scratch.
Yes agree, I do try to write as much comment as possible if time allow it
 

RAMBO999

Joined Feb 26, 2018
259
Hi guys

I am keen to know how you structure your source code, so I can learn something from you guys and improve the way I do things.

So here was how I did it in the past:
Code:
/*!    There are all in the same folder
*    Say under /uart
*/

uart.h
uart.c
Here is how I do it now:
Code:
/*!    There are all in the same folder
*    Say under /uart
*/

uart_def.h            /* constant etc...                */
uart_types.h        /* typedef struct etc...        */
uart_api.h            /* external function prototype    */
uart_api.c            /* private function prototype,
                     * And both private the public
                     * functions body
                     */
                
uart.h                /* application function prototype    */
uart.c                /* application function body        */
How do you guys structure you code, and what do you think I can improve on? Thanks guys!
When I hear the word structure I think in terms of OOP and OOD. Application structure is something else. I don't think there really is an alternative these days to object orientatated design. Application wise it needs to be multilayered eg: presentation layer, middleware, data access layer and data layer. Assuming we are talking about interactive client server type applications. Obviously, when dealing with control systems you don't necessarily need the presentation layer unless it is for admin and maintenance purposes. But the code itself should be desgined along OO lines.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
When I hear the word structure I think in terms of OOP and OOD. Application structure is something else. I don't think there really is an alternative these days to object orientatated design. Application wise it needs to be multilayered eg: presentation layer, middleware, data access layer and data layer. Assuming we are talking about interactive client server type applications. Obviously, when dealing with control systems you don't necessarily need the presentation layer unless it is for admin and maintenance purposes. But the code itself should be desgined along OO lines.
When I asked this question, I have C and embedded in mind. I was hoping to see what others are doing and adapt for my own use.

I like the idea of multi-layer design, that is something have never come across my mind. I understand that you are assuming interactive client server type application. But I would like to know a bit more this multi-layer design thing so I can adapt to my need.

Do you have any pointer that I should google so I can read more about it?
 

djsfantasi

Joined Apr 11, 2010
9,156
You really need to customize your structure around what the code does. The multilayer model works well on the macro-model, but breaks down at the application layer.

Each layer imposes it’s own structure. Most layers can be interpreted in some sort of standardized approach.

But the application layer is unique. I have a run-time application for a proprietary language. It’s structure is dual-layered. The first layer responds to external input. The second layer is a time-sliced multitasking monitor. That structure is unlikely to appear in another application.

You are most likely to succeed when recognizing blocks of code for common tasks. And treating them as independent blocks of code.
 

nsaspook

Joined Aug 27, 2009
13,081
You really need to customize your structure around what the code does. The multilayer model works well on the macro-model, but breaks down at the application layer.

Each layer imposes it’s own structure. Most layers can be interpreted in some sort of standardized approach.

But the application layer is unique. I have a run-time application for a proprietary language. It’s structure is dual-layered. The first layer responds to external input. The second layer is a time-sliced multitasking monitor. That structure is unlikely to appear in another application.

You are most likely to succeed when recognizing blocks of code for common tasks. And treating them as independent blocks of code.
+1

Exactly. The strict adherence to the OOP abstraction/paradigm or some current elegant programming fad to all types of programming tasks sounds cultish. Knowing (insight) what the key objectives of the particular programming project are and translating (decomposition of the problem) that into human mind capacity sized chunks of testable structured programming code and namespace is what's really needed. Program name space is a essential ingredient to good program structure. I don't always write C with good namespace structure but I do think about it even with quick hacks. Before C I programmed in Modula-2 before OOP was a mainstream thing. It contained IMO superior, moré powerful and flexible ways to structure programming than the 50 years old (Simula67) OOP model.

OO does not replace procedural programming, it complements procedural programming when dealing with things like GUI interfaces. It's not the solve-all and be-all of programming.
 
Last edited:

RAMBO999

Joined Feb 26, 2018
259
When I asked this question, I have C and embedded in mind. I was hoping to see what others are doing and adapt for my own use.

I like the idea of multi-layer design, that is something have never come across my mind. I understand that you are assuming interactive client server type application. But I would like to know a bit more this multi-layer design thing so I can adapt to my need.

Do you have any pointer that I should google so I can read more about it?
Embedded C supports OO principles. I haven't read the link below but it sounds like it might help you. There is nothing faddy about OO. I can't think of a programming language or scripting tool that doesn't support at least the basic principle of OO design which is Encapsulation. IDEs too. There is also far and away more valid reason to adopt OO principles than mere style and elegance, although stylish and elegant it certainly is particuarly when compared to the unprincipled and undisciplined approach you often find in what's commonly called procedural programming. ENCAPSULATION is the principle of grouping logically related variables and functions into a single structure called a CLASS structure. Just like any other system component you define the Class structure in a source text document that is loaded into memory when called for by the program when you need to use it at run time. (Or at startup time if deemed necessary). Different languages have different syntax of course so if you looked at two Class definitions for the same Object from two different platforms (eg: C# vs Java) they will look different. But when processed they do the same thing at the machine level. They create a software OBJECT that provides all of the data and functionality that the system requires about that particular entity. This is called INSTANTIATION. You create an INSTANCE of the class in memory space so that you can access it's accessible properties and methods (functions). There are so many advantages to OO it's difficult to document them and a full docmentation is beyond the scope of this forum. But there are some key words an phrases that you could focus on and they are OO Encapsulation, OO Class, OO Object, Class vs Object, OO Inheritance, Dependency Injection, Instantiation, Access Modifiers, Class Properties, Class Methods, Method Signature, Method Overloading, Class Constructors, Class Single Responsibility Principle (SRP), Class Library. I have no doubt missed a few but if you understand these concepts you are on your way. There is an awful lot to cover and at first you will probably find it daunting. You have to think CLASS when you look at data. Much the same as you do when you are putting a database schema together. It requires that you think about organizing your program variables and functions into logical groups/structures. In essence an OBJECT is a structured variable. Have a look at that link. If you have any questions feel free to ask. BTW. You could install one the various free IDEs that are out there on the net and use it to start writing simple class structures, loading them into a simple program and accessing their properties and methods. Small steps to understanding how it works. OO is probably the best thing that happened to software development ever in my opinion. It's prolific throughout the software development industry. It is the ultimate in modular coding. You might have 50, any number, of programs in an application that handle customer data. In a procedural programming system you might have to repeat the customer variable code in every one. If you use OO all you need is ONE customer class definition and you can reference it in any program. That means a single modification to the class is immediately available to every program that uses it. Reusable code is the whole point. That's what Class Libraries are all about. Reusability. And it doesn't get any better than OO. Just look at the number of DLLs on your computer. get yourself an Object Browser software and look through them. You will find OO Class structures in every one. That's the extent of OO's proliferation throughout the software development industry.

http://www.embedded.com/object-oriented-c-is-simple/
 
Last edited:

djsfantasi

Joined Apr 11, 2010
9,156
Can you explain a little further, I don't think I understand what you mean here
Nsaspook also stated this point...
Knowing (insight) what the key objectives of the particular programming project are and translating (decomposition of the problem) that into human mind capacity sized chunks of testable structured programming code and namespace is what's really needed.
Recognize independently testable chunks of structured code that compose your project. Don’t mix input processing code with output calculations, for example.
 

nsaspook

Joined Aug 27, 2009
13,081
Embedded C supports OO principles. I haven't read the link below but it sounds like it might help you. There is nothing faddy about OO. I can't think of a programming language or scripting tool that doesn't support at least the basic principle of OO design which is Encapsulation. IDEs too. There is also far and away more valid reason to adopt OO principles than mere style and elegance, although stylish and elegant it certainly is particuarly when compared to the unprincipled and undisciplined approach you often find in what's commonly called procedural programming. ENCAPSULATION is the principle of grouping logically related variables and functions into a single structure called a CLASS structure. Just like any other system component you define the Class structure in a source text document that is loaded into memory when called for by the program when you need to use it at run time. (Or at startup time if deemed necessary). Different languages have different syntax of course so if you looked at two Class definitions for the same Object from two different platforms (eg: C# vs Java) they will look different. But when processed they do the same thing at the machine level. They create a software OBJECT that provides all of the data and functionality that the system requires about that particular entity. This is called INSTANTIATION. You create an INSTANCE of the class in memory space so that you can access it's accessible properties and methods (functions). There are so many advantages to OO it's difficult to document them and a full docmentation is beyond the scope of this forum. But there are some key words an phrases that you could focus on and they are OO Encapsulation, OO Class, OO Object, Class vs Object, OO Inheritance, Dependency Injection, Instantiation, Access Modifiers, Class Properties, Class Methods, Method Signature, Method Overloading, Class Constructors, Class Single Responsibility Principle (SRP), Class Library. I have no doubt missed a few but if you understand these concepts you are on your way. There is an awful lot to cover and at first you will probably find it daunting. You have to think CLASS when you look at data. Much the same as you do when you are putting a database schema together. It requires that you think about organizing your program variables and functions into logical groups/structures. In essence an OBJECT is a structured variable. Have a look at that link. If you have any questions feel free to ask. BTW. You could install one the various free IDEs that are out there on the net and use it to start writing simple class structures, loading them into a simple program and accessing their properties and methods. Small steps to understanding how it works. OO is probably the best thing that happened to software development ever in my opinion. It's prolific throughout the software development industry. It is the ultimate in modular coding. You might have 50, any number, of programs in an application that handle customer data. In a procedural programming system you might have to repeat the customer variable code in every one. If you use OO all you need is ONE customer class definition and you can reference it in any program. That means a single modification to the class is immediately available to every program that uses it. Reusable code is the whole point. That's what Class Libraries are all about. Reusability. And it doesn't get any better than OO. Just look at the number of DLLs on your computer. get yourself an Object Browser software and look through them. You will find OO Class structures in every one. That's the extent of OO's proliferation throughout the software development industry.

http://www.embedded.com/object-oriented-c-is-simple/
All of the OO principles are 50 years old and were once just called structure programming, so yes, it's good stuff .

The problem is not OOP used correctly as the structured design pattern, the problem is OOP being a religion of programming priests who hold their noses down on the unprincipled and undisciplined mere mortals that actually need to program in the sectors of programming tasks that formal class hierarchical OOP principles don't make real-world sense.
 
Last edited:

RAMBO999

Joined Feb 26, 2018
259
All of the OO principles are 50 years old and were once just called structure programming, so yes, it's good stuff . The problem is not OOP used correctly as the structured design pattern, the problem is OOP being a religion of programming priests who hold their noses down on the unprincipled and undisciplined mere mortals that actually need to program in the sectors of programming tasks that formal class hierarchical OOP principles don't make real-world sense.
The politics and pedentary that more often than not comes out of university classrooms doesn't particularly interest me. The proponents of things like design patterns and the GOF usually have one thing in common and that is that they have never had the responsibility of designing and delivering a well structured, flexible and scalable system to meet a real life commercial system specification within a real life commercial time frame and a real life commercial budget. They can afford to pi55 about. I have been developing software since the mid 1980s, starting with COBOL, with a skill set that now includes most if not all popular modern technlological develpment platforms up to present day. I have worked with many IT graduates and the first thing you have to do is tell them to forget what they have been told and set them out on a path to commercially practicality. Otherwise you get nothing done. So I have no time for the academics. There are those who can do and those who can talk about it. I'm with the doers.
 
Last edited:

RAMBO999

Joined Feb 26, 2018
259
When I asked this question, I have C and embedded in mind. I was hoping to see what others are doing and adapt for my own use.

I like the idea of multi-layer design, that is something have never come across my mind. I understand that you are assuming interactive client server type application. But I would like to know a bit more this multi-layer design thing so I can adapt to my need.

Do you have any pointer that I should google so I can read more about it?
A few words on the structure of the application. The application stucture doesn't have any particular dependency on whether you use procedural program design or OO design although OO design methodologies makes the layering a lot easier to accomplish. Web pages written in Classic ASP, for example, are procedural and will usually contain a mixture of HTML layout code, serverside code referred to as "code behind" and client side scripting code in something like JavaScript or VBScript. As such it makes the seperation of Presentation, Middleware and Data operation extremely difficult and contrived it's not really designed with that in mind. But it can be done.

As I said before you can group your application components into 4 layers (think categories).

The Presentation Layer: This is the code that presents input/output screens to an end user / operator. Typically called forms, or views or screens. Forms that contain input contols like text boxes, text areas, descriptive labels, buttons, radio buttons, dropdown menus and image / chart controls. That sort of thing. You are familiar with forms. Like the view attached.

The Middleware Layer: This is the set of programs that receives the input data submitted by the end user (the form data) or the end user's request for data from the database and handles them. Typically this program code will validate input data to determine its integrity and check for errors reporting any errors back to the end user for correction with an appropriate message if found. If deemed to be acceptable the programs will use a method (function) in the Data Access Layer (DAL) to submit the data to the database. If the end user submits a request for data from the database then the program will use a method (function) in the Data Access Layer (DAL) to submit the request to the database. The database will process the request and return the data to the Data Access Layer method which in turn returns it to the Middleware program. The program will then build a new form (web) or populate the existing form (desktop() using the data presenting it on the screen.

The Data Access Layer: These are not so much programs as scriplets or modules that contain the necessary code needed to accept the data from the Middleware, prepare it for the RDBMS and submit it to the RDBMS and then receive the response. Typically this might involve one Class containing multiple methods one for every type of database interactio required by the Middleware. The syntax associated with database interactions can be different between different DBMSs. MS SQL Server vs Oracle etc. This is partcularly important when you are using Command Text based queries. Not so much Stored Procedure type queries. But is is an important point. Some people write this code inline and embedded inside the Middleware programs particularly in proderural programs like Classic ASP. In this case if you originally write the system to interact with a SQL Server database, say, and then the Company decides to go Oracle later on then you would have to rewrite he entire Middleware section to change the database syntax. If you were a provider of proprietary systems you would effectively have to maintain a seperate system for each DBMS that's on the market. Last time I looked there were 29. By seperating this code out into it's own layer and modules it means that all you have to do is rewrite your Data Access Layer methods. The Middleware remains unchanged. One system, 29 DALs.

The Data Layer. This is effectively you DMBS. But it's an integral part of the system so it sits in its own logical layer.

So data / traffic goes from Presentation -> Middleware -> Data Acess Layer (DAL) - Data Layer and back again. This is what you will often hear referred to as an N-Tier system design. Using OOP and OOD makes this seperation very easy to accomplish. At the end of the day it's all about how you structure you project folders. See the attached screendump. This is the Visual Studio IDE project for the system in the first picture. It is an OO designed system as all of my systems are. I can't get it all on the screen but you can see a number of folders and top level components.

Data Access Layer: BusinessEntities and DALObjects.

Middleware: All top level program modules ending in .aspx.cs and all other folders excluding css, js, Images, DriverImages and Includes

Presentation Layer: All top level program modules ending in .aspx and folders css, js, Images, DriverImages and Includes.

This a .Net web application written using C#.

So you see you just need to think about organising your system.

One of the great things about OO is the reusability of code. This system has 65 user screens. The entire system source code only comes to 42 Mb of source. The economy of scale that can be achieved using OO designed is phenominal. If you use it right. That's why it is now the industry standard for application development.

I started off by saying "A few words" A bit more than a few I think.
 

Attachments

Last edited:

nsaspook

Joined Aug 27, 2009
13,081
The politics and pedentary that more often than not comes out of university classrooms doesn't particularly interest me. The proponents of things like design patterns and the GOF usually have one thing in common and that is that they have never had the responsibility of designing and delivering a well structured, flexible and scalable system to meet a real life commercial system specification within a real life commercial time frame and a real life commercial budget. They can afford to pi55 about. I have been developing software since the mid 1980s, starting with COBOL, with a skill set that now includes most if not all popular modern technlological develpment platforms up to present day. I have worked with many IT graduates and the first thing you have to do is tell them to forget what they have been told and set them out on a path to commercially practicality. Otherwise you get nothing done. So I have no time for the academics. There are those who can do and those who can talk about it. I'm with the doers.
OOP is a specific case abstraction of procedural programming designed to push error detection and mitigation into the compile stage instead of run-time by forcing a specific structure and discipline . It's not independent of procedural programming and it provides no special capabilities to write X special program as they all compile down to ASM code on a hardware CPU. Unprincipled and undisciplined programmers will write horrible code using the OOP abstraction. The main problem I see with most OOP implementations is they're not designed to provide good thread-safe race prevention and the atomic data structure protection needed within the OOP abstraction in many embedded applications. Now C doesn't either but it also doesn't try to hide that fact with a vase of OOP roses. The good C programmer knows it's hard, so they are principled and disciplined programmers.
 

RAMBO999

Joined Feb 26, 2018
259
OOP is a specific case abstraction of procedural programming designed to push error detection and mitigation into the compile stage instead of run-time by forcing a specific structure and discipline . It's not independent of procedural programming and it provides no special capabilities to write X special program as they all compile down to ASM code on a hardware CPU. Unprincipled and undisciplined programmers will write horrible code using the OOP abstraction. The main problem I see with most OOP implementations is they're not designed to provide good thread-safe race prevention and the atomic data structure protection needed within the OOP abstraction in many embedded applications. Now C doesn't either but it also doesn't try to hide that fact with a vase of OOP roses. The good C programmer knows it's hard, so they are principled and disciplined programmers.
"designed to push error detection and mitigation" How so?
 

MrChips

Joined Oct 2, 2009
30,708
The problem with modern stuff is that it has become so complex that people don't have time to learn the basics.
Hence today's users, as well as programmers, designers and engineers have to depend on layers and layers of complex stuff in order to get anything accomplished. One cannot create a PC, tablet, or smart phone app without using OOP.

Structured programming was forced upon me after seeing the pitfalls of Fortran, BASIC, and ASM (my first ventures into computer science). Then I moved to ALGOL, Pascal, and C.

Putting things into their proper perspectives, all of my projects are stand-alone embedded systems using small, medium, and high performance MCUs. (I did create a CAD app for Apple Macintosh but that was eons ago.) I have no need for OOP, RTOS, or any OS.

Hence to me, structure means (and this is what I believe the TS is asking) how you organize your project files and folders, .c and .h files. To me it also means how you write manageable code, maintainable 10-25 years down the line. It also means how to take advantage of #include, #define, data type and struct in order to make your code more readable and manageable.

Using third party libraries can be advantageous. However, sometimes they get in the way of performance and you just have to go back to basics, get to bare metal by writing to the hardware directly.
 

nsaspook

Joined Aug 27, 2009
13,081
"designed to push error detection and mitigation" How so?
Stronger static typing.

https://en.wikipedia.org/wiki/Type_safety#C++

In general:
In computer science, type safety is the extent to which a programming language discourages or prevents type errors. A type error is erroneous or undesirable program behaviour caused by a discrepancy between differing data types for the program's constants, variables, and methods (functions), e.g., treating an integer (int) as a floating-point number (float). Type safety is sometimes alternatively considered to be a property of a computer program rather than the language in which that program is written; that is, some languages have type-safe facilities that can be circumvented by programmers who adopt practices that exhibit poor type safety. The formal type-theoretic definition of type safety is considerably stronger than what is understood by most programmers.

Type enforcement can be static, catching potential errors at compile time, or dynamic, associating type information with values at run-time and consulting them as needed to detect imminent errors, or a combination of both.

The behaviors classified as type errors by a given programming language are usually those that result from attempts to perform operations on values that are not of the appropriate data type. This classification is partly based on opinion; it may imply that any operation not leading to program crashes, security flaws or other obvious failures is legitimate and need not be considered an error, or it may imply that any contravention of the programmer's explicit intent (as communicated via typing annotations) to be erroneous and not "type-safe".

In the context of static (compile-time) type systems, type safety usually involves (among other things) a guarantee that the eventual value of any expression will be a legitimate member of that expression's static type. The precise requirement is more subtle than this — see, for example, subtype and polymorphism for complications.
The real problem is that just about any real-world interactive program will have unsafe non-static coded elements, so there are limits to what we can check in a static (compile-time) manner.

Some quotes from the Inventor of C++
Bjarne Stroustrup's FAQ


Why did you invent C++?
I wanted to write efficient systems programs in the styles encouraged by Simula67. To do that, I added facilities for better type checking, data abstraction, and object-oriented programming to C. The more general aim was to design a language in which I could write programs that were both efficient and elegant. Many languages force you to choose between those two alternatives.
...
Please note that object-oriented programming is not a panacea. "OOP" does not simply mean "good" - if there are no inherent hierarchical relationships among the fundamental concepts in your problem then no amount of hierarchy and virtual functions will improve your code. The strength of OOP is that there are many problems that can be usefully expressed using class hierarchies - the main weakness of OOP is that too many people try to force too many problems into a hierarchical mould. Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran).
 

RAMBO999

Joined Feb 26, 2018
259
Stronger static typing.

https://en.wikipedia.org/wiki/Type_safety#C++

In general:

The real problem is that just about any real-world interactive program will have unsafe non-static coded elements, so there are limits to what we can check in a static (compile-time) manner.

Some quotes from the Inventor of C++
Bjarne Stroustrup's FAQ


Why did you invent C++?
I wanted to write efficient systems programs in the styles encouraged by Simula67. To do that, I added facilities for better type checking, data abstraction, and object-oriented programming to C. The more general aim was to design a language in which I could write programs that were both efficient and elegant. Many languages force you to choose between those two alternatives.
...
Please note that object-oriented programming is not a panacea. "OOP" does not simply mean "good" - if there are no inherent hierarchical relationships among the fundamental concepts in your problem then no amount of hierarchy and virtual functions will improve your code. The strength of OOP is that there are many problems that can be usefully expressed using class hierarchies - the main weakness of OOP is that too many people try to force too many problems into a hierarchical mould. Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran).
Ok. I see where you are coming from. I was thinking in terms of transactional errors, error handling and so forth and, of course, OO doesn't make that any more likely. OO is just a design methodology. It's all down to the programmer and far too many consider it optional. I think the term is "strongly typed". Which doesn't mean everything is written in capitals with bold face. (joke). That's one of the things I like about strongly typed environments actually.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
Hence to me, structure means (and this is what I believe the TS is asking) how you organize your project files and folders, .c and .h files. To me it also means how you write manageable code, maintainable 10-25 years down the line. It also means how to take advantage of #include, #define, data type and struct in order to make your code more readable and manageable.
That's exactly what I want to ask:eek::eek:
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
A few words on the structure of the application. The application stucture doesn't have any particular dependency on whether you use procedural program design or OO design although OO design methodologies makes the layering a lot easier to accomplish. Web pages written in Classic ASP, for example, are procedural and will usually contain a mixture of HTML layout code, serverside code referred to as "code behind" and client side scripting code in something like JavaScript or VBScript. As such it makes the seperation of Presentation, Middleware and Data operation extremely difficult and contrived it's not really designed with that in mind. But it can be done.

As I said before you can group your application components into 4 layers (think categories).

The Presentation Layer: This is the code that presents input/output screens to an end user / operator. Typically called forms, or views or screens. Forms that contain input contols like text boxes, text areas, descriptive labels, buttons, radio buttons, dropdown menus and image / chart controls. That sort of thing. You are familiar with forms. Like the view attached.

The Middleware Layer: This is the set of programs that receives the input data submitted by the end user (the form data) or the end user's request for data from the database and handles them. Typically this program code will validate input data to determine its integrity and check for errors reporting any errors back to the end user for correction with an appropriate message if found. If deemed to be acceptable the programs will use a method (function) in the Data Access Layer (DAL) to submit the data to the database. If the end user submits a request for data from the database then the program will use a method (function) in the Data Access Layer (DAL) to submit the request to the database. The database will process the request and return the data to the Data Access Layer method which in turn returns it to the Middleware program. The program will then build a new form (web) or populate the existing form (desktop() using the data presenting it on the screen.

The Data Access Layer: These are not so much programs as scriplets or modules that contain the necessary code needed to accept the data from the Middleware, prepare it for the RDBMS and submit it to the RDBMS and then receive the response. Typically this might involve one Class containing multiple methods one for every type of database interactio required by the Middleware. The syntax associated with database interactions can be different between different DBMSs. MS SQL Server vs Oracle etc. This is partcularly important when you are using Command Text based queries. Not so much Stored Procedure type queries. But is is an important point. Some people write this code inline and embedded inside the Middleware programs particularly in proderural programs like Classic ASP. In this case if you originally write the system to interact with a SQL Server database, say, and then the Company decides to go Oracle later on then you would have to rewrite he entire Middleware section to change the database syntax. If you were a provider of proprietary systems you would effectively have to maintain a seperate system for each DBMS that's on the market. Last time I looked there were 29. By seperating this code out into it's own layer and modules it means that all you have to do is rewrite your Data Access Layer methods. The Middleware remains unchanged. One system, 29 DALs.

The Data Layer. This is effectively you DMBS. But it's an integral part of the system so it sits in its own logical layer.

So data / traffic goes from Presentation -> Middleware -> Data Acess Layer (DAL) - Data Layer and back again. This is what you will often hear referred to as an N-Tier system design. Using OOP and OOD makes this seperation very easy to accomplish. At the end of the day it's all about how you structure you project folders. See the attached screendump. This is the Visual Studio IDE project for the system in the first picture. It is an OO designed system as all of my systems are. I can't get it all on the screen but you can see a number of folders and top level components.

Data Access Layer: BusinessEntities and DALObjects.

Middleware: All top level program modules ending in .aspx.cs and all other folders excluding css, js, Images, DriverImages and Includes

Presentation Layer: All top level program modules ending in .aspx and folders css, js, Images, DriverImages and Includes.

This a .Net web application written using C#.

So you see you just need to think about organising your system.

One of the great things about OO is the reusability of code. This system has 65 user screens. The entire system source code only comes to 42 Mb of source. The economy of scale that can be achieved using OO designed is phenominal. If you use it right. That's why it is now the industry standard for application development.

I started off by saying "A few words" A bit more than a few I think.
That is more than I am asking for, thank you very much for replying in details!!
 
Top