Aquarus
asked on
Web based application for a complete newbe
I was joined the team that is about to start developing of the web based application.
The architecture is such:
1. The application will run on XXXX-Intranet, and the users will login using their AS accounts.
2. Presentation - web server: IIS 7, .Net 4, ASP.Net, C#, Telerik controls
3. Business Logic and Data Access - application server: .Net 4
4. Data - SQL server
I am practically jumping into that and I need to understand what is that architecture description means. Please suggest some reading for the beginners.
I have experience developing the C# - SQL application with 2-tier model - BL and PL and windows forms.
The architecture is such:
1. The application will run on XXXX-Intranet, and the users will login using their AS accounts.
2. Presentation - web server: IIS 7, .Net 4, ASP.Net, C#, Telerik controls
3. Business Logic and Data Access - application server: .Net 4
4. Data - SQL server
I am practically jumping into that and I need to understand what is that architecture description means. Please suggest some reading for the beginners.
I have experience developing the C# - SQL application with 2-tier model - BL and PL and windows forms.
kaufmed
Did you mean "AD" accounts, as in Active Directory? If not, what is "AS"?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Given the proximity of the S and D keys on the keyboard I assumed AD :)
ASKER
Yes, experts. I am really sorry for my mistyping. AD , not AS. Thank you for your comments.
I'll start reading what is suggested by QPR.
I'll start reading what is suggested by QPR.
Definitely read up on n-tier architecture as QPR suggests. In a nutshell, this is what I understand the above to be:
1. You will have a web application that is only accessible on your company's local network--i.e. no one from the Internet can access the app. To secure this app, Active Directory credentials will be used to authenticate users. This could be because the app will have different parts that only apply to different subsets of users. For example, you might have an "administration" page that is only accessible by managers. Such individuals might be given an "admin" role in AD that the web app would check for before serving up any administration pages.
2. This should be a bit self-explanatory. You're building a web app. The majority of the time you will host this in IIS (version 7 as indicated above)--your web server software. It's going to be an ASP.NET web site targeting version 4.0 of the .NET Framework, with a C# code-behind. Telerik is a software development company. One of the products they offer is a suite of web controls to help make development of RIA (rich internet applications) easier. You will apparently be using some of their controls.
3. Your "business layer" is where your business rules go. "Should a currency field allow alphabetic characters?" "Should I submit an order for processing if there are zero items in the shopping cart?" Business rules validate how your application should treat the data it recieves.
Your "data layer" is a section of your application whose only job is to interact with the database. You will often hear the term "CRUD"--create, read, update, delete--mentioned when discussing a data layer. These are the operations you perform when interacting with a database. You create new records in the database with INSERT statements; you read records from the database with SELECT statements; you update records in the database with UPDATE statements; you delete records from the database using DELETE statements. Your data layer is responsible for setting up all the logic that manages these statements. The rest of your application doesn't concern itself with the syntax the database requires--this is the data layer's job.
The reason you do this is for ease of swapping out the data layer if your back-end database changes. If you switch databases, and the new database doesn't support one of the (SQL) language features you originally used, then updating this logic is completely transparent to the rest of the application. Your application only knows that the data layer provides a "Create" method to insert a record into the database; it has no idea how this happens.
4. This is just the database that was chosen by the team. The data layer will be the part of your application that talks with this piece of the system.
1. You will have a web application that is only accessible on your company's local network--i.e. no one from the Internet can access the app. To secure this app, Active Directory credentials will be used to authenticate users. This could be because the app will have different parts that only apply to different subsets of users. For example, you might have an "administration" page that is only accessible by managers. Such individuals might be given an "admin" role in AD that the web app would check for before serving up any administration pages.
2. This should be a bit self-explanatory. You're building a web app. The majority of the time you will host this in IIS (version 7 as indicated above)--your web server software. It's going to be an ASP.NET web site targeting version 4.0 of the .NET Framework, with a C# code-behind. Telerik is a software development company. One of the products they offer is a suite of web controls to help make development of RIA (rich internet applications) easier. You will apparently be using some of their controls.
3. Your "business layer" is where your business rules go. "Should a currency field allow alphabetic characters?" "Should I submit an order for processing if there are zero items in the shopping cart?" Business rules validate how your application should treat the data it recieves.
Your "data layer" is a section of your application whose only job is to interact with the database. You will often hear the term "CRUD"--create, read, update, delete--mentioned when discussing a data layer. These are the operations you perform when interacting with a database. You create new records in the database with INSERT statements; you read records from the database with SELECT statements; you update records in the database with UPDATE statements; you delete records from the database using DELETE statements. Your data layer is responsible for setting up all the logic that manages these statements. The rest of your application doesn't concern itself with the syntax the database requires--this is the data layer's job.
The reason you do this is for ease of swapping out the data layer if your back-end database changes. If you switch databases, and the new database doesn't support one of the (SQL) language features you originally used, then updating this logic is completely transparent to the rest of the application. Your application only knows that the data layer provides a "Create" method to insert a record into the database; it has no idea how this happens.
4. This is just the database that was chosen by the team. The data layer will be the part of your application that talks with this piece of the system.
ASKER
Thank you, Kaufmed. Your explanation is very helpful. And I am reading the QPR's link.