|
Just out of curiosity why is someone voting down a post without any reply ?
company, work and everything else @ netis
|
|
|
|
|
because noone has a clue what you're asking about????
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
I know I don't have a clue what dOOdads are or is all about and you've given no links to describe what it is either.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
You're right. dOOdads is a tool for O/R mapping and code generation of data layers.
Here is the link
|
|
|
|
|
We evaluated dOOdads when we looked at MyGeneration, but we ended up going with DevExpress' eXpress Persistent Objects. It fits in better with our client architecture and doesn't require us to fit in with plumbing that doesn't quite match our needs.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
I actually asked another version of this before but this time I am just curious about the .NET to .NET part. I no longer work for the company that was attempting this but it still makes me curious. The company wanted to have a web server, an app server, and the database (SQL) server.
I get the web and database servers, I've done that. What I dont understand is why go through all the trouble to take all of the business logic and place it on an App Server behind the fire wall and only do presentation code on the web server.
How feasible is this with .NET?
They are currently doing this with Classic ASP and VB6 because they have a way to tell the app to use the COM objects on another box or something along those lines but with .NET it seems that you have to have another web server behind the firewall for this to work because you would need to be able to either use a web service or .NET remoting right???
Cleako
-- modified at 9:40 Thursday 15th February, 2007
|
|
|
|
|
Security is the first thing that comes to mind. When dealing with an internet based application you only expose what you absolutely need to. By exposing your presentation layer machine only you given yourself a small amount of risk. Now - no matter how much your server gets attacked - that is the only part of the business that will be affected. If there are other internal machines that rely on the business layer they will be able to use that business layer just fine while your internet users are the only ones having trouble.
Patrick Allmond
http://allaboutfocus.com
|
|
|
|
|
Would this be implemented using the .NET Remoting/Web Service option? It seems to me that if you expose the internal server using web protocols that it could be hacked.
Cleako
|
|
|
|
|
cleako wrote: because they have a way to tell the app to use the COM objects on another box
You could do the same thing with a ASP.NET web service and COM+ business objects. Although I fail to understand the benefit.
led mike
|
|
|
|
|
cleako wrote: What I dont understand is why go through all the trouble to take all of the business logic and place it on an App Server behind the fire wall and only do presentation code on the web server.
That's interesting, because I did some work for a company wanting to do the same thing. However, the reasoning there was to first develop an App server with a rich presentation client, then a web server as merely a different sort of rich presentation "client". In both cases, the business logic would be on the app server.
As to feasible, regardless of what technology you use, it's actually very difficult. They never succeeded. I think it's doable though.
Marc
Thyme In The CountryInteracxPeople are just notoriously impossible. --DavidCrow There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
|
Their thought is that it is safer having the business logic on the app server, but I thought that .NET took care of the security issue by building the code into DLLs.
Cleako
|
|
|
|
|
Isolating the business logic behind the firewall may be an attempt to reduce the attack surface of the application. The risk is that once a web server is attacked, the attacker can then discover the attack path through the firewall.
Another reason to use an n-tier infrastructure is to reduce the load on the web server.
The risk in this scenario is that a performance bottleneck can be created between web server and app server by relatively slow network technology.
.NET remoting does not require the HTTP protocol, and therefore, has no requirement for a web server. One way to think of .NET remoting is an evolution of the COM/DCOM model.
The risk here is that you are restricted to Microsoft technologies on both communication endpoints.
Web services requires a web server, and is restricted to the HTTP protocol.
If you really want to start to understand the ins and outs of n-tier development in relation to .NET, locate a copy of
"Microsoft® .NET Distributed Applications: Integrating XML Web Services and .NET Remoting" by Matthew McDonald copyright 2002
It references ASP.NET 1.x, and it provides examples of how to evolve a VB6/COM application to .NET.
This is an easier said than done process.
HTH,
onemorecoder
|
|
|
|
|
Is it necessary to encrypt viewstate from web.config even when SSL is being used? Does it provide any additional benefit or does it just slow down the server without any additional benefit?
Thanks,
Sam
|
|
|
|
|
Viewstate is already encrypted as is, the option to mess with it's encryption is to utilize a stronger routine.
I am not an absolute security expert but I know some things so i would suggest that anything you can keep on the server you keep there and just utilize the viewstate for holding the data of non-sensitive material. If you are accepting whether or not they like pizza, by all means use the viewstate, if you are taking an SSN, then you should probably grab that value and hold it in a session variable and replace it on the page with the bullets and dont even mean anything.
Cleako
|
|
|
|
|
ViewState is base64 encoding. SSL is encrypting the channel communications.
|
|
|
|
|
Keep in mind that viewstate also slows down the transmission time and increases the bandwidth usage because it makes your page larger. .NET holds the viewstate information in a hidden form field so the text for that data is sent on each page request. Because of this, the user could try to modify the viewstate and send it back - so keep sensitive data in the session or in some data store on the server.
|
|
|
|
|
Is there a security threat to ASPNET session id cookie for session hijacking even when SSL is used? Please advise. Also, same question for Forms Authentication Cookie.
Thanks,
Sam
|
|
|
|
|
Hi, im looking for a deployement strategie.
I've been looking into a few techniques, Windows installer and click once installer.
Both are nice but they bot have their downsides. The best technique would be one equal to suns JAVA runtime files (Just a webpage with a download and installation bar)
Requirements for the installation:
The application is based on the .NET framework 2.0;
The .NET framework 2 must be installed whenever the framework is missing.
A solution for installing under limited rights would be wonderfull!
An easy to edit configuration file of the setup project would be nice because there will be multiple instance of a single application ( This aint required or what )
I Hope i'm posting this in the right section,
Thanks already!
- Koen
|
|
|
|
|
Hello,
I'm designing an application that simulates a university application and courses system.
I'm looking for a design pattern for this case:
I have a base class Course, and 3 deriving classes for 3 type of courses.
each course should have a list of pre-courses that need to be taken in order to take the course. The pre courses can be any of the 3 types of courses.
I thought of using the graphic-shape-picture design pattern, but it's not the very same case.
Will appreciate any idea!
Thank You
Orlya
|
|
|
|
|
Maybe the "Course" class has a collection of Course class references or Course class unique id's.
led mike
|
|
|
|
|
Hi,
Any suggestions on how I can build an client/server architecture which has a browser-based RIA (Rich Internet Application using flex, .NET 3.0 or other) client and a server architecture that can run either on a web server (SOAP/Web services), or as an ordinary TCPIP-based application server. The option for deployment will be given the user at install time.
I understand that I need to write communication services for both options, but what is the optimal choice of technology/method?
The goal is to give the option to install the application on a standalone PC without IIS or any other web server installed, but still let the user interface be browser based.
Jay
|
|
|
|
|
|
Thanks. However, don't focus on the RIA part of my question. That is only to show that I want a "modern" browser-based UI experience. It is the dual-protocol communication strategy which is the interesting part to me. I want to have a web/internet application (default) to be able to run on a standalone computer environment which hasn't got a webserver installed.
Jay
|
|
|
|
|
We are having some communictions problems. You want an internet application without the internet?
If you want to use a Web Browser interface for your UI in a desktop application you can use the WebBrowser control.
At this point I have no idea what you are trying to accomplish.
led mike
|
|
|
|
|
Jay
You need to be a little more clear on what you mean by web server and ordinary based TCPIP-based application server.
By web server I am assuming you literally mean a web server as in Apache or IIS. And TCPIP-based application serevr, I assume you mean Tomcat, Websphere, etc. Right?
I am currently creating an RIA using flex with a .NET backend.
dan
|
|
|
|