30. september 2004 - 13:11Der er
24 kommentarer og 1 løsning
Implementering af 3-Tier
Vi vil gerne vide hvordan man implementerer en 3-tier arkitektur.
Vores problem er at vi ikke præcist ved hvordan vi foretager kaldene ned gennem vores 3 tiers. Hvordan skal vores kald se ud, når de går fra brugergrænsefladen (presentation tier) ned til forretningslaget (business tier) og videre til data access tier?
Vi har f.eks. en klasse BRUGER, og vi vil gerne have en komplet liste af de BRUGERE som findes i vores DB, vist i brugergrænsefladen.
Vi søger et fuldstændigt eksempel, hvor vi kan se kaldene i gennem alle 3 lag og tilbage igen.
Presentation - vores C#.NET website Business logic - Vores klasser (f.eks. user.cs) Data Access - vores klasse(r), der skal varetage al kommunikation til selve databasen.
Vi søger altså et helt konkret eksempel på, hvordan vi foretager kald fra voes GUI til til vores Business tier, og videre ned til vores Data Access tier, der så endlig forespørger i selve database.
Den arkitektur vi har tænkt os at benytte kan i se en grafisk illustration af her:
Hvis vi nu tager udgangspunkt i et helt konkret eksempel:
En besøgende kommer ind på vores websit, og vil se en komplet liste over vores Brugere - eksempelvis i et datagrid. Han går derfor ind på vores users.aspx-side, hvor vi har opstillet en form til at liste samtlige brugere i systemet. Dvs. at brugeren ved at klikke på en knap (f.eks. "Vis brugere"), indirekte skal kalde en metode i vores Business tier, der så kalder videre ned igennem Data laget.
Hvis i arbejder med codebehind så vil users.aspx (presentation) jo have en users.aspx.cs (logic) med en metode som kaldes ved page load. Den metode kalder så noget i db.cs (data) som henter de rette data fra databasen. En datagrid gør vel at DTO mellem logic og data bliver f.eks. en ArrayList.
Den måde, som du er inde på er jo en 2-lags model, hvor Business logic bliver "sprunget over". Vi havde tænkt os at lave ASP.NET applikationen fuldstændig objektorienteret...
det ved vi Arne, men... vil den måde du forslår så ikke gøre selve vores reelle klasser overflødige - efter som der ikke oprettes nogen objekter af de klasser, som vi har fundet frem til via vores udviklingsmetode (OOA&D).
Når du skriver at du betragter users.aspx.cs som værende business logic, er det så ikke ADO.NET, der reelt er din business logic ???
Grunden til at vi vil oprette de tre lag (tiers) skyldes at Microsoft selv anbefaler det, da ulemperne ved en 2-tiers app er meget større end den tre-delte:
-------TAGET FRA MSDN ------- Two-Tier Application Architecture:
A typical two-tier application is a client application using ADO.NET communicating directly with a database server, like Microsoft SQL Server™ (see Figure 1). There are no intervening layers between the client application and the database other than ADO.NET. For more information on ADO.NET, see the .NET Framework documentation, other articles in this series or use the MSDN search engine.
When to Use a Two-Tier Architecture ----------------------------------- A two-tier application is appropriate for a small application that does not have a lot of forms, or perhaps no forms at all. It may also be appropriate for prototypes where the final version of the application uses one of the other n-tier techniques described in this article. A two-tier application is not well suited, however, to an enterprise environment, because development and maintenance time and costs can become unmanageable.
Typical Implementation Options ------------------------------ There are several techniques you can use to develop a two-tier application. All use ADO.NET with a client interface, such as a desktop or Web-based application, and a database, such as SQL Server. Ideas for how to approach the architecture of a two-tier application include:
Use data binding techniques to connect an ADO.NET dataset directly to controls. Write code that accesses ADO.NET objects to load data manually into controls on your user interface. Use a combination of the above two techniques. Code business rules directly on the forms with any of the above techniques.
Advantages -------------
A two-tier application has the following advantages:
Development can be quick and easy because you can use data binding to connect an ADO.NET dataset directly to many of the controls used to build the user interface. This helps you get the basic functions of an application up and running quickly.
You can see an application's entire code by looking in just your forms. There is no need to look at both your forms and into another component to see the code.
Disadvantages ------------- The two-tiered application development method has the following disadvantages:
All business rules are contained in the front-end code. As a result, if you need to change a business rule, all clients must be updated. Unless you have an automated update approach, this can be a maintenance nightmare. Of course, if you use SQL Server, you can put some business rules into stored procedures to decrease maintenance time and costs.
Although SQL can provide a level of abstraction between the database structure and the rest of the application, field names are often hard-coded into the source code or control properties. If you change a field name, you have to find and replace every occurrence in your application. When data binding is involved, you also have to check all forms and change properties.
A lot of code—SQL statements and business rules, for example—is often repeated throughout the application because various forms use some of the same tables. This makes maintaining this type of application very difficult because if you need to change the name of a table or a field, you have to change it in multiple places. It also requires extra regression testing in multiple locations.
Changing the code used to load data into a dataset is more difficult if the source of that data changes. For example, if you use a text file to store your data and then switch to SQL Server, the access method is quite different. In addition, many areas will require code changes in order to load data into your application's dataset.
Ulemperne er (ifølge MS langt mindre) ved den tre-delte (Logical N-Tier Application):
-------TAGET FRA MSDN -------
Logical N-Tier Applications --------------------------- The best approach to building an application using .NET is to separate all logical processes into discrete classes. In a typical business application, this generally involves a business rule component, a data layer component, and the front-end code that uses these components. Figure 4 illustrates this approach.
When to Use an N-Tier Architecture Using a logical n-tier development strategy is appropriate for all types of applications. It works equally well in small, medium, and large applications, and with both desktop and Web applications.
Typical Implementation Options You will most likely use the following development techniques to create this type of application:
Create the front-end user interface using either Windows Forms or Web Forms. Create the business rule component as a separate Class Library project. Create a data layer component as a separate Class Library project. This data layer uses classes to wrap up access to each table. Typed datasets should be used; they provide the flexibility of the dataset class and strong typing for each column in the tables.
Advantages: ----------- A logical n-tier application has the following advantages:
Centralizes business rules into a component that is easy to create, use, and re-use. This makes development and maintenance easier.
Provides a high-level language in which to develop business rules, as opposed to using stored procedures and limited SQL language for business rule checks. Centralizes the data access into a component. This means less repeated code throughout your application; each form that needs to access a specific table always uses the same component.
If you use typed datasets, you get the benefit of looking up column names using IntelliSense instead of having to remember them.
Centralized data access routines help with maintenance, since changes to any data access routine need be made only once.
Provides the flexibility to separate components onto different physical machines at any time. This helps with scalability and better centralization of code.
Disadvantages: -------------- A logical n-tier application has only two significant disadvantages:
Development takes a little longer because you must build separate components.
There are a few more components to track. This makes this development method a little more complicated to understand for new programmers.
Forestil dig nu at du skulle overføre penge fra en konto til en anden konto.
Så ville det give mening med:
transfer.aspx med HTML tags transfer.aspx.cs med button click -> action transfer.cs med check for om der er penge på fra konto etc. og selve overførslen konto.cs med forskellige klasser for forskellige slags konti
Om koden i transfer.aspx.cs så skal kaldes presentation eller business logic kan man jo så diskutere.
Arne -> Mht. dit indlæg 30/09-2004 14:54:22, så kan jeg forstå på dig, at du IKKE opretter reelle objekter, når du laver .NET websites, eller tager jeg fejl?
Men det første jeg kommer til at tænke på er, om det nu også er den rigtige måde? Selv om jeg nu må indrømme, at det er meget fristende at gøre, da vi slipper for at afsætte memory-resourcer til vores objekter i form af contructer-kald, og vi får en større perfomance.
Men bør man ikke (er det ikke hele konceptet med .NET) at lave denne opdeling ???
Grunden til at jeg/vi spørger så meget ind til det, skyldes at vi jo gerne vil have de faglige argumenter på plads - uanset hvilken fremgangsmåde vi så ender ud med at gøre brug af.
Det jeg skitserede 14:54:22 har 3 source filer for henholdvis presentation, logik og data. Men det er rigtigt at Det bliver kun til 2 objekter på runtime, da siden og code behind merges sammen.
Memory forbrug og constructor kald betyder ikke noget.
Det som betyder noget er maintainability.
Adskillelsen mellem siden og code behind er helt essentiel i ASP.NET for vedligeholdelsen.
I det konkrete tilfælde kan jeg ikke se at man vinder noget ved at lave noget passthrough kode mellem code behind og data klasserne. man får bare mere kode at vedligeholde.
I mere komplekse problem stillinger som f.eks. 15:42:41 giver det mening.
[og hvis I læser jeres MSDN udklip vil I se at MS også skelner mellem små og store løsninger]
Men jeg er udpræget pragmatiker. Der er ingen grund til at gøre noget bare for at gøre det. Der skal være et formål.
Vil det sige, at du ikke ser nogen grund til at oprette seperate business logic-klasser, hvis man ikke skal bruge funtionaliteter ala transaktioner?
Systemet vi skal lave, består af to del-systemer. En PDA-applikation (i rent C#)i form af et elektronisk scorekort til golfspillere. Vi deres PDA uploader de så deres score til serveren.
De kan så besøge websitet (der er det andet del-system), hvor brugeren ligeledes har mulighed for at indtaster sine score (hvis vedkommende ikke ejer en PDA). Derudover skal brugeren hovedesageligt kunne se oplysninger og se statistikker over sit spil.
Så du har vel lidt ret i din antagelse: præsentation: HTML logik: page load -> vis brugere data: SQL (SELECT * FROM users)
Jeg tror bare at jeg forstår business logic lidt anderledes, da jeg altid har opfattet det som værende de klasser, som fremkommer af min analysefase (altså bruger, golfbane, scorekort, golfklub, hul etc.)
Men gør jeg/vi det på den måde du foreslår, kommer vi vel helt uden om disse klasser, så snart de er mappet over i databasen - har jeg ret ?
Hvis jeg nu spørger pænt, kan jeg så ikke få dig til at lave et lille eksempel, hvor du viser hvordan din code-behind vil se ud - for jeg er stadig ikke helt med, hvad du så vil have liggende der.
jeg er helt med på at din page-load og button_cliked metoder ligger der,...men hvad ligger der ellers. Er det bare metoder direkte til dit Data Access tier ???
Arne, jeg er desværre nød til at smutte på arbejde nu - men lover at vende tilbage asap !!!
En god grund til at lave separate business logic klasser i jeres eksempel er for at dele logik mellem web app og PDA app.
Hvis der er noget som kræver mere end en linie kode.
Hvis vis score kan kalde en metode i en data klasse som returnerer en ArrayList, så er der ikke meget at dele.
Men hvis den skal checke om brugeren har adgang til de oplysninger, kunne selektere/sortere på forskellige kriterier og den slags, så er der lige pludselig noget reelt funktionalitet.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
