ASP.NET 2 app_code and app_data

As a web programmer, I am prototyping an XML data transfer WS app in ASP.NET 2(is it a good choice?). Some class object files are placed under folder app_code, while XML data files are placed under folder app_data. If later on the users want to change my app to a winform or windows service app, how easy or hard will the change be and what will have to be done about those files sitting under app_code and app_data? Please advise a goodd plan. Thanks.
ksfokAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

JimBrandleyCommented:
We had the same needs when designing our product, but it wasn't a case of either/or, we needed to support both. Our solution was to isolate the afinity for solution type into a small separate assembly. Our business object assembly and data access assembly are used both in a large web app and various support services we have created. Anything that cares about whether or not it's a web app, other than the GUI layer, resides in the separate assembly that we can swap out. It works for us.

Jim
0
ksfokAuthor Commented:
Please kindly elaborate on the technical details of implementation.
0
JimBrandleyCommented:
Starting at the bottom, is the DataAccess assembly. It takes care of communicating with whatever kind of database the customer is using. Sitting above that is the business object assembly.

Each business object requires one object in its constructor, that is our Context object. This object is created once by the application, whether a web app or a Windows service or application. The context object contains a reference to a single instance of the data access class. It manages all transactions. It also handles all references to another assembly we use to contain code that may need to change, depending on whether the app is a web app or a Windows app. The business objects all communicate with that assembly through the context object. That way we can easily swap one for the other as needed.

The layers above the business objects vary depending on the application, but they go down through the same business objects.

Does that help?

Jim
 
0
Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.

ksfokAuthor Commented:
Are app_code and app_data folders used for all projects? How are assemblies be created? Any good text or tutorial to learn what you have done?
0
JimBrandleyCommented:
We do not use folders called app_code or app_data. That doesn't mean you cannot use them. Creating an assembly as part of a solution is pretty easy.

Open the Solution Explorer.
Right-click on your solution
From the context menu, Select Add/New project
From the ensuing dialog, select Class Library
Give it a name and a path.
The new project will create a DLL, in .Net speak, that's an assembly.

Now you can start adding classes to that assembly.

There is probably a tutorial somewhere - you might try MSDN. I just played with it till I got it to do what I wanted. I think the easiest way, at least the way I learn best, is to create some simple "play" solutions. Start with the typical "Hello world" app of the flavor (Windows/Web/Console) that you want to learn. Then when it's time to try something new, prove your concept out in your "sandbox" before applying it to your production code.

Jim
0
ksfokAuthor Commented:
The .dll can be generated under c:\dev\ on box1 and XCOPY to d:\prod\ on box 2 and still runs? Please confirm. Thanks.
0
JimBrandleyCommented:
As long as it bears the same relationship to the directory that contains the executable that loads the assembly(DLL) you should be fine. By default, MSDev puts binaries for Debug builds under a Debug directory, and Release binaries under a Release directory.

Since developers work in debug mode, but out build machine works in Release mode, that can present a problem. So, we set all projects to dump the binary for both modes in a Bin directory under the project. Then when we build an executable that links to our assemblies, we set it to copy the binaries into a Bin directory under the solution. That arrangement works well for us.

Jim
0
ksfokAuthor Commented:
Please kindly provide examples of what you said. Thanks.
0
JimBrandleyCommented:
To set the location for an assembly, open the solution or project in which you are working. Right-click the project in the solution explorer. From the context meny, select Properties. From that page, select the Build tab. You can set the output directory. The output directory for the solution works the same way.

To set the solution to copy referenced assemblies to the local bin directory, Expand the References node under the solution in the solution explorer. Right click an assembly, and select Properties. In the properties window, set Copy Local to True.

Jim
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
ASP.NET

From novice to tech pro — start learning today.