Pros/cons Of Reading Connection String From Physical File Versus Application Object
Apr 9, 2010
my ASP.NET application reads an xml file to determine which environment it's currently in (e.g. local, development, production).
It checks this file every single time it opens a connection to the database, in order to know which connection string to grab from the Application Settings.
I'm entering a phase of development where efficiency is becoming a concern. I don't think it's a good idea to have to read a file on a physical disk ever single time I wish to access the database (very often).
I was considering storing the connection string in Application["ConnectionString"].
[code].....
I didn't design the application so I figure there must have been a reason for reading the xml file every time (to change settings while the application runs?) I have very little concept of the inner workings here. What are the pros and cons?
So I started working on my first asp.net application that involves logging in and databases, and soon after i started messing around with a static class. I "discovered" that if you make a variable static, all sessions share that variable (I for some reason was originally assuming that each session had its own copy of that "static" class). Anyway, after discovering this I thought to myself "how could this possibly be useful to me" and thought that itmight be a good idea to make a single static database connection for all of the sessions, rather than storing that as a session variable for each session. Does anybody know what would be the pros and cons of this approach?
We're converting a Classic ASP site to an ASP.NET site. One function was to upload a 'template' of data in CSV format for importing into the database. There were several different record types in there (the first field always indentifies the type of data).
The task was to get the CSV into a DataTable so it could be validated (new project is to have MUCH better validation rules)
The code seemed pretty straightforward - watered down (taking out comments, Try/Catch, etc) it is as follows:
Dim da As New System.Data.OleDb.OleDbDataAdapter Dim cn As New System.Data.OleDb.OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & strDirectory & ";" & "Extended Properties=""Text;HDR=No;FMT=Delimited;""") Dim cd As New System.Data.OleDb.OleDbCommand("SELECT * FROM " & strCSVFilename, cn) cn.Open() da.SelectCommand = cd da.Fill(dtData)
The DataTable (dtData) is populated, but only starting with the second line of the CSV file DESPITE the fact that "HDR=No" is in the connection string. What am I missing here?
I'm building a new website and How to use the asp.net membership for the authentication process (login, registration, password recovery, etc..). I saw that everything is stored in an XML file. I would like to know what are the pros and cons using the membership instead of to build something from scratch.
Possible Duplicate: When do you use the “this” keyword? In programming you can use the this keyword this.Textbox or just Textbox What is the best practice? Some benefits I can see is that using this makes it easier to see in intellisense and makes it easier to understand that it is a property. Currently I don't use this... I read in some article somewhere that the guy removed all the references, but I don't remember why.
I am a solutions developer in India. I have been working on traditional ASP.net for some time and have been hearing alot about MVC framework. So, i am writing this Post just to have some reviews from you all that what are the major pros and cons of MVC framework. And in which areas/ cases it is suited the most, i mean business websites or commercial websites or Casual Websites. Just to add i am into developing MES portals for Manufacturing companies. So, would want to know is MVC suitable for the same.
What are the pros and cons of the following 2 cases: Case I: Traditional way: Add service reference in project. Create object and Get data from service on server side and bind to asp.net grid. Case II: Update Service for JSON behavior. Add service reference in project. Call service from javascript to get data. Bind data to jquery grid. Which one is the best approach and why?(Not developer point of view)
ASP.NET provides a basic set of Login Controls that integrate with the ASP.NET Membership and Forms Authentication providers. I wouldn't mind being able to skip re-inventing the wheel on this kind of functionality, but I'm wary that there may be security, performance or usability reasons to consider rolling my own.
This is possibly the worst kind of religious debate -- a religious debate with practical consequences. But it's one that needs to be had, and I can't seem to fit it in my tiny head. Here are the pros and cons of the pattern as I know them:
Pros:
-Encourages DRY (don't repeat yourself) design in that identical queries are written only once per set of query conditions -Facilitates unit testing by allowing itself to be abstracted into an interface -Creates an opportunity for business-level validation
Cons:
-Breaks DRY philosophy in that you're generally repeating your database schema -In a sense breaks separation of concerns, because the query concerns of the controller and view frequently become the concerns of whoever is maintaining the repository -Determining what should be a repository and what should be returned as a raw associated ORM entity becomes an ambiguous art
To me it seems like all this stuff should be done at the ORM level, but Entity Framework has much fewer hooks than Linq to Sql does, yet Entity Framework tends to be regarded as being more robust, so it seems that this is by design, and that the designers of EF are in fact encouraging another layer. Are there any tools or anything that I could be using for this? Am I missing something?
We develop an ASP.Net web application that is hosted on an internal network. Currently, we have some ASPX pages that handle web requests from the client side and interact with our servers. We are starting development on our next major application version, and we are deciding on the architecture. What are the differences between using ASPX pages to handle http requests as compared to using a full blown Web Service (which would most likely be a WCF Service)? In researching this issue, I have come across a few related posts that have been moderately helpful, seen here and here. My understanding of some of the key differences are as follows:
ASPX pages are limited in the kinds of requests they can receive. They are strictly HTTP whereas a WCF service can have multiple endpoints to service a variety of protocols (HTTP, TCP, etc). WCF Services are more concretely defined due to ServiceContracts. This means that if a project makes a reference to the service, they know exactly what to expect in terms of methods, usage and documentation. An ASPX page is more of a free for all in terms of methods contained and requests accepted. However, based on these concepts, my issues are as follows:
The ability to support different protocols is a great feature in terms of future proofing and compatibility, but what real benefit are we seeing if we are currently only using it to interact via HTTP? In line with my previous argument, if we are only interacting with the service over a web, do any of those points really make any difference? An http request doesn't care about any of those finer details or contractual guarantees so long as the method it calls "just works".
Is there anything I am missing? Any key benefit to using a service? Personally, I support the Web Service architecture. I like the idea of having a flexible and well defined system that can support future development. What I am basically looking to get out of this is a way to go to a coworker and say "This should be a service for x y z reasons and we could see a b c improvements for doing so".
I am building a web application that will not only require a standard user/pass authentication, but users will need to reside at certain locations to authenticate. My initial thought is to have those locations set up with static ips, that I can look for in the request for authentication. I am mostly a programmer and not an expert in http and iis. I am hoping to get some good advice as to what the pros and cons to this approach will be. Also, VPN to the web server is not an option. This web application will be exposed to the web.
I was wondering what your thoughts were in regards to utilizing SQL Server Views as objects in the entity framework? It would only be used for reading data versus modifiying it.
I want to add quartz scheduling to an ASP.NET application.It will be used to send queued up emails.What are the pros and cons of running quartz.net as windows service vs embedded.My main concern is how Quartz.NET in embedded mode handles variable number of worker processes in IIS.
I've read several other questions on this topic (here, here, and here), but have yet to see a great answer. I've developed my fair share of data access layers before and personally prefer to use instance classes instead of static classes. However, it is more of a personal preference (I like to test my business objects, and this approach makes mocking out the DAL easier). I have used static classes to access the database before, but I've always felt a little insecure in the appropriateness of such a design (especially in an ASP.NET environment).
Can anyone provide some good pros/cons with regards to these two approaches to developing data access classes with ADO.NET providers (no ORM), in an ASP.NET application in particular. Feel free to chime in if you have some more general static vs. instance class tips as well.
In particular, the issues I'm concerned about are:
Threading & concurrency Scalability Performance Any other unknowns
What are the pros and cons between using the ASP.Net control compared to the old reliable table html implementation. I know that the asp:Table will end up on the returned page as a html table, and from looking into it so far people are saying its easier to work with the asp:Table in the server side code, but I'd love to hear what the stackoverflow community has to say about the matter.
I've debated a bit with a colleague of mine whether or not to check in the "project dll". I haven't found any resources/information on this at all.For example: I have a project Foo with a reference to some external class library which isn't supported by me (maybe some open source or such).
Naturally, the external class library dll is commited to the versioning system. Although the Foo.dll (which I compile everytime) does not, according to me, belong in the versioning system. This because it can currupt releases since it does not force the user to compile after check out. Other than that, I haven't found any good arguments other than this. But I've never seen anyone checking in the "project dll".According to my colleague, the "project dll" is commited every time a change has required compilation (naturally, when the dll is changed, it's commited).
But it shows me an errormessage when I run this query:
string query = "Select * from [IO_Definition$]";
IO_Definition is the name of the spreadsheet in my excel file. I also added the excel file to the App_Data folder of the website.
The error is:
The Microsoft Jet database engine could not find the object 'IO_Definition$'. Make sure the object exists and that you spell its name and the path name correctly.
The thing is, when I write the absolute path of the excel file in the connectionString it does work. Is there anyway I can make it work without writing the absolute path?
on VWD 2005 this code works fine, but on 2008 it says I haven't created an instance of the object. I want to convert the object connString (a connection string) into a string.
'This acceses the virtual directory web.config file for connection strings 'We have to convert the object to a connection string Dim rootWebConfig As System.Configuration.Configuration rootWebConfig = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("/VirtualDirec") Dim connString As System.Configuration.ConnectionStringSettings connString = rootWebConfig.ConnectionStrings.ConnectionStrings("ConnectString1") Dim strConnString As String = connString.ToString().......
just for my testing purpose i know i can define both the connection's outside in a single web config file by different name's and access them in my front end according to it but what if i want to have seprate for both connection's web.config situation is like this see image so i want to access my connections from second web config file how i can do that.
I have a db connection string 'ApplicationServices' defined in the connectionString section of web.config and 3 Entity Framework connection strings which have the provider connection string attribute with the same connection string as the one in 'ApplicationServices'. Is there a way to reference connectionString in 'ApplicationServices' for the provider connection string attribute of the EF connection string in the web.config, rather than providing the connection string all over again?
