|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Architecture Adviceapplication and I'd appreciate any advice on architecture. The application is similar to a membership management system at a multi-site chain -- like a fitness center chain. Tasks include: - Add new member - from any site or over the web - Edit member - Sign in/confirm member - at a location (enter ID, confirm photo) - Reporting - Etc. Simplest approach would be 2-tier client server and be done with it. However, it would be nice to be able to provide some data caching at the sites, so we can do some basic tasks if the network goes down -- like sign in a member. And I can see some benefit to having the client apps isolated from the database itself in case we ever want to move away from SQL Server, although that's not a central design goal. Any suggestions or experiences that might steer me to one solution or another? Candidates include: 1. 2-tier client/server 2. middle tier on the server accessed with .net remoting 3. middle tier distributed at the sites that includes some data caching 4. distributed database using replication when network is online 5. others I'm not thinking of Thanks for any war stories / advice! kc kcamhi wrote:
Show quote > I'm going to be using SQL Server (thanks for that advice) for a distributed ---Considering how easy it is to create true n-Tier components in .NET, > application and I'd appreciate any advice on architecture. > > The application is similar to a membership management system at a multi-site > chain -- like a fitness center chain. > > Tasks include: > - Add new member - from any site or over the web > - Edit member > - Sign in/confirm member - at a location (enter ID, confirm photo) > - Reporting > - Etc. > > > Simplest approach would be 2-tier client server and be done with it. > > However, it would be nice to be able to provide some data caching at the > sites, so we can do some basic tasks if the network goes down -- like sign in > a member. > > And I can see some benefit to having the client apps isolated from the > database itself in case we ever want to move away from SQL Server, although > that's not a central design goal. > > > Any suggestions or experiences that might steer me to one solution or > another? Candidates include: > > 1. 2-tier client/server unless this is a small app that won't grow, I'd build it n tier. > 2. middle tier on the server accessed with .net remoting --You have two basic approaches, .NET Remoting/COM+ or Web Services. Web Services are built on top of .NET Remoting so for performance, you're going to get more out of Remoting, and TCP over Binary is going to be notably faster that using WS which entails SOAP over HTTP > 3. middle tier distributed at the sites that includes some data caching --This isn't mutually exclusive from #2. I'd definitely look to caching. Check out the Caching Application block for some really good ideas on how to implement it > 4. distributed database using replication when network is online --Not sure I follow you on this, as opposed to what for instance?> 5. others I'm not thinking of For this, I think using Remoting and making it NTier is your best bet. Remember that all you have to do to make it remotable is inherit your classes from MarshallByRefObject. You can also host your components in IIS for instance, and using interfaces on the client, you can have a system that will allow you to drop in new DLLS and you won't have to touch or recompile your client/middle teir components. You can handle all such issues through config files. Also, you can split up your components so that everything is remotable so you can split the load over multiple machines. If you don't need/ want to up front, then you can load everything on one machine (so it's client/server). Then if the base grows or you need performance/security associated with splitting things up, it's literally only a matter of copying files and chaning config file settings - nothing else. This is huge. > HTH,> Thanks for any war stories / advice! > kc Bill Thanks Bill - that's very helpful.
Show quote "W.G. Ryan" wrote: > kcamhi wrote: > > I'm going to be using SQL Server (thanks for that advice) for a distributed > > application and I'd appreciate any advice on architecture. > > > > The application is similar to a membership management system at a multi-site > > chain -- like a fitness center chain. > > > > Tasks include: > > - Add new member - from any site or over the web > > - Edit member > > - Sign in/confirm member - at a location (enter ID, confirm photo) > > - Reporting > > - Etc. > > > > > > Simplest approach would be 2-tier client server and be done with it. > > > > However, it would be nice to be able to provide some data caching at the > > sites, so we can do some basic tasks if the network goes down -- like sign in > > a member. > > > > And I can see some benefit to having the client apps isolated from the > > database itself in case we ever want to move away from SQL Server, although > > that's not a central design goal. > > > > > > Any suggestions or experiences that might steer me to one solution or > > another? Candidates include: > > > > 1. 2-tier client/server > > ---Considering how easy it is to create true n-Tier components in .NET, > unless this is a small app that won't grow, I'd build it n tier. > > 2. middle tier on the server accessed with .net remoting > --You have two basic approaches, .NET Remoting/COM+ or Web Services. > Web Services are built on top of .NET Remoting so for performance, > you're going to get more out of Remoting, and TCP over Binary is going > to be notably faster that using WS which entails SOAP over HTTP > > 3. middle tier distributed at the sites that includes some data caching > --This isn't mutually exclusive from #2. I'd definitely look to > caching. Check out the Caching Application block for some really good > ideas on how to implement it > > 4. distributed database using replication when network is online > --Not sure I follow you on this, as opposed to what for instance? > > 5. others I'm not thinking of > For this, I think using Remoting and making it NTier is your best bet. > Remember that all you have to do to make it remotable is inherit your > classes from MarshallByRefObject. You can also host your components in > IIS for instance, and using interfaces on the client, you can have a > system that will allow you to drop in new DLLS and you won't have to > touch or recompile your client/middle teir components. You can handle > all such issues through config files. Also, you can split up your > components so that everything is remotable so you can split the load > over multiple machines. If you don't need/ want to up front, then you > can load everything on one machine (so it's client/server). Then if > the base grows or you need performance/security associated with > splitting things up, it's literally only a matter of copying files and > chaning config file settings - nothing else. This is huge. > > > > Thanks for any war stories / advice! > > kc > > HTH, > > Bill > kcamhi wrote:
Show quote > Thanks Bill - that's very helpful. My pleasure man. If yhou need any help on the implementation, please > > > "W.G. Ryan" wrote: > > >>kcamhi wrote: >> >>>I'm going to be using SQL Server (thanks for that advice) for a distributed >>>application and I'd appreciate any advice on architecture. >>> >>>The application is similar to a membership management system at a multi-site >>>chain -- like a fitness center chain. >>> >>>Tasks include: >>>- Add new member - from any site or over the web >>>- Edit member >>>- Sign in/confirm member - at a location (enter ID, confirm photo) >>>- Reporting >>>- Etc. >>> >>> >>>Simplest approach would be 2-tier client server and be done with it. >>> >>>However, it would be nice to be able to provide some data caching at the >>>sites, so we can do some basic tasks if the network goes down -- like sign in >>>a member. >>> >>>And I can see some benefit to having the client apps isolated from the >>>database itself in case we ever want to move away from SQL Server, although >>>that's not a central design goal. >>> >>> >>>Any suggestions or experiences that might steer me to one solution or >>>another? Candidates include: >>> >>>1. 2-tier client/server >> >>---Considering how easy it is to create true n-Tier components in .NET, >>unless this is a small app that won't grow, I'd build it n tier. >> >>>2. middle tier on the server accessed with .net remoting >> >>--You have two basic approaches, .NET Remoting/COM+ or Web Services. >>Web Services are built on top of .NET Remoting so for performance, >>you're going to get more out of Remoting, and TCP over Binary is going >>to be notably faster that using WS which entails SOAP over HTTP >> >>>3. middle tier distributed at the sites that includes some data caching >> >>--This isn't mutually exclusive from #2. I'd definitely look to >>caching. Check out the Caching Application block for some really good >>ideas on how to implement it >> >>>4. distributed database using replication when network is online >> >>--Not sure I follow you on this, as opposed to what for instance? >> >>>5. others I'm not thinking of >> >>For this, I think using Remoting and making it NTier is your best bet. >>Remember that all you have to do to make it remotable is inherit your >>classes from MarshallByRefObject. You can also host your components in >>IIS for instance, and using interfaces on the client, you can have a >>system that will allow you to drop in new DLLS and you won't have to >>touch or recompile your client/middle teir components. You can handle >>all such issues through config files. Also, you can split up your >>components so that everything is remotable so you can split the load >>over multiple machines. If you don't need/ want to up front, then you >>can load everything on one machine (so it's client/server). Then if >>the base grows or you need performance/security associated with >>splitting things up, it's literally only a matter of copying files and >>chaning config file settings - nothing else. This is huge. >> >>>Thanks for any war stories / advice! >>>kc >> >>HTH, >> >>Bill >> let me know, I'll be glad to help Kcamhi,
Be aware that an ASPNet application with ADONET is forever a 3Tier. The browswer is your Client UI which is independent from any other client The DLL created by ASPNET is your middle tier which interact between your clients and the data The Database server is your dataaccess tier. This does not mean that you can connect in your middle tier to other tiers as Bill showed by instance by using remoting. Just as addition. Cor Cor,
That hardly qualifies the application to be 3 tier. Would you also then argue that because .NET sits on COM which sits on Win32, which sits on Assembly and IRQs, all of those are layers? What is the definition of a layer per you? The two definitions I've heard are physical and logical. And an ASP.NET app out of the box is hardly a 3 tier application by any stretch of imagination. - Sahil Malik [MVP] ADO.NET 2.0 book - http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx __________________________________________________________ Show quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:uScxR72EGHA.3856@TK2MSFTNGP12.phx.gbl... > Kcamhi, > > Be aware that an ASPNet application with ADONET is forever a 3Tier. > > The browswer is your Client UI which is independent from any other client > The DLL created by ASPNET is your middle tier which interact between your > clients and the data > The Database server is your dataaccess tier. > > This does not mean that you can connect in your middle tier to other tiers > as Bill showed by instance by using remoting. > > Just as addition. > > Cor > Sahil Malik [MVP C#] wrote:
Show quote > Cor, Sahil - I agree with your assessment but I guess it all depends on how > > That hardly qualifies the application to be 3 tier. Would you also then > argue that because .NET sits on COM which sits on Win32, which sits on > Assembly and IRQs, all of those are layers? What is the definition of a > layer per you? The two definitions I've heard are physical and logical. And > an ASP.NET app out of the box is hardly a 3 tier application by any stretch > of imagination. > > - Sahil Malik [MVP] > ADO.NET 2.0 book - > http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx > __________________________________________________________ > > > "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message > news:uScxR72EGHA.3856@TK2MSFTNGP12.phx.gbl... > >>Kcamhi, >> >>Be aware that an ASPNet application with ADONET is forever a 3Tier. >> >>The browswer is your Client UI which is independent from any other client >>The DLL created by ASPNET is your middle tier which interact between your >>clients and the data >>The Database server is your dataaccess tier. >> >>This does not mean that you can connect in your middle tier to other tiers >>as Bill showed by instance by using remoting. >> >>Just as addition. >> >>Cor >> > > > you define layers. Typically I'd think of it in terms of an appdomain or an executing assembly. With IE it's just a conduit, everything is executing on the server so it's not the same as having a winforms app which consumes a dll remotely which calls some DALC remotely. Ultimately I guess it depends on how you define tiers but I'm in agreement with your definition here. Bill,
For me a tier processes its data independend from another assembly. This is a complete different from a layer which is in fact a connected part of the assembly. I have seen often told that a layer is a tier, which is in my opinion absolute not true. Remoting is for me a typical sample from what is using a extra tiers. In an ASPNET application are all actions by the way exectuted in ASPNET on the browser. (It only asks to start a process as to refresh the data or whatever on the server) If you open the source in your browser from an ASPNET application than you can see how much scrambled and not scrambled Javasctript is in that. Cor Cor Ligthert [MVP] wrote:
Show quote > Bill, I'm not sure I follow you though. My point earlier was simply that it > > For me a tier processes its data independend from another assembly. > > This is a complete different from a layer which is in fact a connected part > of the assembly. > > I have seen often told that a layer is a tier, which is in my opinion > absolute not true. > > Remoting is for me a typical sample from what is using a extra tiers. > > In an ASPNET application are all actions by the way exectuted in ASPNET on > the browser. (It only asks to start a process as to refresh the data or > whatever on the server) If you open the source in your browser from an > ASPNET application than you can see how much scrambled and not scrambled > Javasctript is in that. > > Cor > > all depends on how you define a tier but in standard parlance, a simple aspnet app isn't considered ntier. Again it depneds on definition. In an ASP.NET app, all the actions aren't executed in a browser, on the contrary, other than client side script, it all executes on the server. HTTP is stateless so it has to execute in a completely disconnected fashion. So in traditional lingo, the web server itself is the client and makes remote calls to a db or app server. In a remoting scenario that can change although it depends on where you host the assemblies. But when most people talk of 3 -Tier it's a reference to the UI layer, the application layer and the db layer. THis can be expanded greatly with remoting/web services but that's traditionall what's meant. Bill,
> You can almost completelely do your verification against business rules do > In an ASP.NET app, all the actions aren't executed in a browser, on the > contrary, other than client side script, it all executes on the server. in the browser, it is what you prefer. That client side script is processing you know. For me that is exactly what tiers do, seperate the processing parts assynchronous from each other. It seems maybe for you not that way because it is so easy to do with an ASPNET application. It generates in the most simple way for you standard a complete UI in the browswer. Which is not the same as the code that you have made. However feel free to have another opinion than me. Cor But the business rules seldom occur client side. Sure, client side
validation of controls occur but you can have an ASP.NET application without javascript or any client side scripts. That's why you need to check for post backs, b/c a trip is made back to the server where everything happens. Again, it's probably a difference of definitions but in virtually every discussion I've ever been in, every presentation and every book, tiers are defined differently then your definition. I'm not saying it's wrong, but your original statement that all ASP.NET applications are 3 tier needs to be clarified b/c by the most widely used definitions of the term, that simply isnt true. Show quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:eRNOPxbFGHA.3064@TK2MSFTNGP10.phx.gbl... > Bill, > >> >> In an ASP.NET app, all the actions aren't executed in a browser, on the >> contrary, other than client side script, it all executes on the server. > > You can almost completelely do your verification against business rules do > in the browser, it is what you prefer. That client side script is > processing you know. For me that is exactly what tiers do, seperate the > processing parts assynchronous from each other. > > It seems maybe for you not that way because it is so easy to do with an > ASPNET application. It generates in the most simple way for you standard a > complete UI in the browswer. Which is not the same as the code that you > have made. > > However feel free to have another opinion than me. > > Cor > Bill,
As I always write don't misquoute me, I hate it if that is done, you would know that. > I'm not saying it's wrong, but your original statement that all ASP.NET I explicitely did not write it in that way.> applications are 3 tier needs to be clarified b/c by the most widely used > definitions of the term, that simply isnt true. >Sure, client side validation of controls occur but you can have an ASP.NET A postback is a message to the UI messages handling tier which replies (or >application without javascript or any client side scripts. That's why you >need to check for post backs, b/c a trip is made back to the server where >everything happens. not a message) to the UI tier. You wrote in my opinion in fact what the interaction between tiers is. Checking can in my opinion be needed in any tier of an application. Cor Cor - I in no way was trying to misquote you or take your comments out of
context. Here's what you said and this is what I was responding to: <<Be aware that an ASPNet application with ADONET is forever a 3Tier.>> Where exactly did I misquote you? Show quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:%23j27vyzFGHA.2084@TK2MSFTNGP09.phx.gbl... > Bill, > > As I always write don't misquoute me, I hate it if that is done, you would > know that. > >> I'm not saying it's wrong, but your original statement that all ASP.NET >> applications are 3 tier needs to be clarified b/c by the most widely used >> definitions of the term, that simply isnt true. > > I explicitely did not write it in that way. > >>Sure, client side validation of controls occur but you can have an ASP.NET >>application without javascript or any client side scripts. That's why you >>need to check for post backs, b/c a trip is made back to the server where >>everything happens. > > A postback is a message to the UI messages handling tier which replies (or > not a message) to the UI tier. You wrote in my opinion in fact what the > interaction between tiers is. > > Checking can in my opinion be needed in any tier of an application. > > Cor > Bill,
> You wrote <<I'm not saying it's wrong, but your original statement that all > <<Be aware that an ASPNet application with ADONET is forever a 3Tier.>> > > Where exactly did I misquote you? ASP.NET applications are 3 tier>> An ASPNET application without ADONET is by instance in my opinion not a 3Tier. Cor But just so I understand you, you are saying that I misquoted you there?
The presence of ADO.NET doesn't define a teir in any way that I've ever heard the word and the implication, within the context of what else you said is pretty clear... namely that a Web app without ADO.NET is still 2 teir right? <<An ASPNET application without ADONET is by instance in my opinion not a > 3Tier. >> This is precisely the point I'm taking issue with. If you have Similarly, you can have an ASP.NET application that has all the DALC > a web application that calls a web service or remotes objects, lets say > that you have , for the sake of discussion, 3 application servers so you > remote a string object through three application servers back to the > client - this isn't N-Teir in your opinion? (It doesn't use ADO.NET after > all) . You have your asp.net site call appserver1 which performs business > logic and calls apperver2 which performs some other business logic which > in turn calls appserver3 which handles credit card processing. It sounds > like you're saying this 'isn't' N-Tier b/c of the abscence of ADO.NET. If > that's your point I think you're just incorrect on it. components in the same project. Moreoever what if you had no dalc layer, you just connected to the db directly from your page. Where is the tier? One project that contains all the business and Data Access logic running on one machine. Again it sounds like your implying that this is a 3 teir architecture. The issue I have is that you're implying that because you're using a browser that it somehow changes the architecture. What if I ran the app in terminal services mode? It sounds like you would reason that this is a n-teir application? Finally, you can use ADO.NET without ever touching a database. So if you have a ASP.NET application that uses a dataTable (ADO.NET) to store user settings, and everything was created/existed in the same project, your statement <<Be aware that an ASPNet application with ADONET is forever a 3Tier.>> is misleading without clarifying it and that's all my point was. If you had a one page application in ASP.NET that had one datatable in it and no other classes - that meets your criteria but it doesn't meet the criteria of a n-Tier application by any use of the word that I've ever come across. I've maintained that this whole discussion seems predicated upon differences in definitions - so if you'd be so kind, I'd love to read where teirs are differently than they are in all the books and presentations I've seen. Show quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:ujaZ5OzGGHA.608@TK2MSFTNGP14.phx.gbl... > Bill, > >> >> <<Be aware that an ASPNet application with ADONET is forever a 3Tier.>> >> >> Where exactly did I misquote you? > > You wrote <<I'm not saying it's wrong, but your original statement that > all ASP.NET applications are 3 tier>> > > An ASPNET application without ADONET is by instance in my opinion not a > 3Tier. > > Cor > Bill,
>. I've maintained that this whole discussion seems predicated upon Books are often parroting. The same way as once is proved in California that >differences in definitions - so if you'd be so kind, I'd love to read where >teirs are differently than they are in all the books and presentations I've >seen. children become from cabbage Try to see it from my point of view where a windowsform application is exchanging messages with a remoting service or a webservice. For me a webbrowser communicating almost the same messages with the DLL created on whatever webserver (in can as well be the data part of a classic ASP application by the way, that part is not sent to the browswer, the browser does there as well only the UI handling). However feel free to have another opinion with me. I agree that I had connected ADONET to much with a databaseserver, it can be with ADONET without a databaseserver (which I see as a separate tier) as well be a 2Tier application. And with this even more telling that for me an ASPNET application is not forever a 3Tier. By the way Tiers and Datalayers are different things for me. I see them often described as if they are the same. However feel free to have another opinion about this than me. Cor Doh,
Tiers and Layers. I hope you don't mind that I want to stop this thread, I thought that everything was said. :-) Cor |
|||||||||||||||||||||||
Other interesting topics