I currently have a visual basic console application that runs on the server nightly and that has several classes. Each class has lots of properties as well as quite a few procedures and functions doing various tasks.
I have a payer class that handles information and functions dealing with payers, a recipient class that handles information and functions dealing with recipients and I have a payment class that holds information about payments. Two of the payment class properties are of payer type and recipient type. Part of my application creates a PDF out of all of this information and faxes it to the recipient.
Now I also have a asp.net website that displays information about all of these payers, recipients, and payments. Currently it does not access anything the console application has. It just gets information from the database and displays it in various list views and things.
The client is now asking to have a button on the website that would allow them to recreate the pdf that the console application currently generates. There is a lot of code involved in this and I need a way to not duplicate it.
My thought was to make a webservice that handles creating the pdf and both the application and the website could call it. But the web service will need access to these custom classes that currently live in my console application.
What would be the best way for both my webservice and the console application to have access to these classes. Would it then be possible to pass a custom object of type payment as a parameter to the webservice?
Using a class library
I had a similar situation where I had to share some classes and functions between projects. What I did was to create a Class Library and put those classes there. Also, when I created the library I had some issues with namespaces so I had some rewriting to do on that part.
So, essentially my solution was separated in two projects
The core library (class library)
The website (ASP.NET web application)
In the core library I had all code regarding the Data Access Layer, all the entity classes of my application and a bunch of helper classes, tools etc while in the website I did not leave much code except from the code involved in the pages and user controls.
With this approach you will have an extra .dll file containing the shared classes that the console application, the webservice and the web application will share.
Keep in mind that there are some things that you need to keep in mind such as the connection string where each application might store it in a different place. Also you cannot use the Request, Response, Server etc namespaces in your library since it will be null in the case of the desktop application.
Using linked files
An other way to share code between projects is to have the code files in one project and link those files to the other.
Right click in your project and choose Add -> Existing item, and then click the down arrow next to the Add button and select Add as link:
Finally this thread is about this subject, so it might be useful.
Related
We currently have an application that is usable by several clients, it is used to download and store data from our application that they have on their environment.
We have a need to pass this application over to a developer but at the same time, we need to protect our code. The way that I see it working is that we would like to some how consider our current app a framework, allowing another app to be created on top of it, but the app may have its own screens, but re-use some of the built-in screens.
Is it possible to protect our app in such a way with out rewriting everything into protected DLL's? Or should we just suck it up and share our code with consulting firms that want to build these types of apps for our clients?
If your proprietary code is entirely focused on downloading and storing data. You could create an online REST api that returns the data over the internet. The other developer could then just request the data from your servers using an HTTP call.
However if your code needs to be client-side, the only real thing you can do is compile a DLL, and even then that can be decompiled.
I'm pretty new to the whole coding thing (hence the name). I've recently written my first website asp.net 4/Visual Studio etc.
I now want to write some code that can be shared amongst websites (my own only). At first I thought of a pluggable class library solution to store the code centrally, however, it seems a class library does not have certain things like config files to store my configuration,and I began to wonder if a class library is the right choice, or whether another web application would be better suited.
The solution will be code/configuration only with no pages.
So, a couple of questions.
Can a web app be incorporated into another web app?
Is a web app the right way or should I stick with a class library solution?
Is there a checklist I should follow before making such a decision?
Sorry if these questions appear rather basic, but as I said, I've little experience in this area.
Thanks in advance.
I always mix in class libraries with my web applications. I have many class libraries for each web application. Your class libraries will have access to the Web.config file for your web application, you just need to add the System.Configuration namespace.
I would break our your class libraries into logical pieces. As an example, I have a class library for database access, for third party API access, and another for active directory access. Break your libraries into logical pieces that can be easily reused among your other web applications.
It's absolutely a good idea to separate your webpages from the logic via class library projects.
"Can a web app be incorporated into another web app?" I believe only compiled code can be incorporated into other projects, and that wouldn't include aspx pages, so no.
"Is a web app the right way or should I stick with a class library solution?" - I prefer web app(s) with separate class libraries. Take the instance where you would want separate client-facing and admin sites, and maybe you have a call center version that is (for example) a native winforms application. I would have a solution with two webapp projects, a winforms project, and shared class libraries to support all three UI versions. We also have a couple standalone libraries (as in, not in the same solution as a webapp) like our logging or custom authentication solutions that we drop in to new web app solutions.
"Is there a checklist I should follow before making such a decision?" - I've created a VS template that has a web app project and a class library by default. I don't think there's any choice to be made, it's just what we do.
I am trying to understand different artifacts around implementing Tridion XPM. Unfortunately I did not find any article that has answers to my questions.
For example Content delivery server (on WebSphere) can have four different applications, one for Content delivery(which handles publishing), one for web service (oData implementation), one for XPM (with Session preview) and the actual preview application. I am assuming we can merge one or more of these applications into one for a simple implementation (with one or two consuming websites).
My questions are:
How can we simplify the number of applications (WARs) to be made? Though I always prefer to keep the preview application separate from Tridion's framework. What are the benefits around Content Delivery session preview Web service as a standalone Java/JSP Web application Versus adding it to existing application?
How can I associate/integrate webservice(oData) to XPM or other common basic functionality like component linking?
For example if I publish a page with out enabling oData it will split tridion:ComponentLink tag where as if I enable it will split tcdl:Link tag. So I need to come up with custom class to read these tags? which eventually require adding Tridion framework in the preview application. (Assuming I did not include any Tridion framework in my preview to have a clean application dependency)
I looked at Tridion's live site for more information, but I could not find much useful info for my questions.
There's a LOT of questions right there, let's see what I can do here.
You will need 3 applications:
A Deployer (standard deployment configuration)
A Staging Website (with Tridion stack + XPM Filters + Ambient Framework)
A WebService app (OData + Ambient Framework)
XPM itself runs in the Content Manager Explorer, so it's not per se a separate app, it's an extension of the Tridion Content Manager.
If you want to have your staging separate from Tridion, then you will not be able to use "Session Preview", which in turn means you do not need OData. This however will revert back to the SiteEdit days whereby every change you do to pages requires the page to be republished (with Session Preview this is immediate).
You do NOT need to use OData for your Website in any way (unless you really want to). The WebService is there to support Session Preview only. I wrote down the interactions between XPM/CME/Staging site here and they're documented here.
If you publish tcdl:link code to OData, then just use TCDL/REL, Tridion will render it for you, you don't need to custom parse anything.
Hope this helps...
I am new to .NET and ideally want to make several layers of abstraction for making a fairly complex website. Being the first layer handling login, authentication, etc, with another layer handling the built in apps (how they look, predefined functions, database connections), and the lower level will be specific app implementation details.
This favors uniformity as all apps will inherit from one place allowing for easier maintenance and rapid development of all the smaller apps once the overhead abstraction layers handle their responsibilities.
The only problem is I am not 100% sure where to start with .NET ASP webpage inheritance. I tried Google and searching but I may not be looking for the right thing. I am hoping with someone with experience on the matter may direct me towards resources to make this kind of webpage inheritance/abstraction easier!
I am using Visual Studio 2010.
Edit:
I also want to add the purpose to my question: Another individual is creating the base of the website which will handle authentication, portal, UI look, etc
I want to make an app base that uses their website framework and adds onto it standards that every app must meet, function library, any addition UI overrides not applicable from portal, etc.
From there a third layer that will directly inherit from the above app base framework (abstraction) and further specify based on the guide lines made.
I appreciate the feedback so far!
In ASP.NET you have 4 common ways to reuse code/abstractions to serve you application-wide
The first way is just using a base page, which will inherit the standard asp.net Page and share the common logic for all of your pages, as explained here
The second way is using a master page: a master page defines a common design (html / css - wise) for all the pages that use it throughout the application. It can also be accessed programmatically by pages that use it, and therefore share a common logic
The third way is using an http module: An http module is basically a class, which is responsible for handling an HTTP request before its handled by the expected pages code on the server, and it allows you to add any common logic you want your application to use (such as authentication / authorization handling, getting relevant user information from the DB, etc)
Global.asax: contains application/session wide event handlers, which allow you to handle those events in once place (everything from application starting to a user session ending)
Using modules and base page is the preferred way, if you want to build few applications, sharing common behaviour. A master page can be used as well, of course, if you want them to share the same design as well.
That's quite a broad question. Welcome to ASP.NET!
I would suggest researching these topics:
Web page inheritance -> Master Pages,
Skinning -> App_Themes,
separation of responsibilities -> MVP design
pattern for the Web Forms platform, or MVC if you have a choice.
Login, roles -> Membership
I have an intranet application that needs contact information for various locations on our campus that are served by our IT lab support organization. We have an enterprise directory that contains contact information so I'm not keeping the actual contact information in the database, but rather an immutable identifier that serves as a key to look the person up in our enterprise directory (via a web service). I'll be looking contact information up via a publicly available web site.
The problem comes in that the id that is useful to the web-based directory lookup is only "sort of" immutable and is not the id that I will store in the database. Directory lookups are most easily performed using the person's Active Directory login id. What I will be using is called the Master Records Unique ID.
My question is: where is the most reasonable place to do the translation from MRUID to Active Directory login id for the link?
Right now I'm doing the translation in the presentation layer, with application-level caching to reduce look ups to the directory. Currently there is only a single web site, but I would expect that if there are other web sites that need to do this, I would migrate the helper class to a shared web controls library.
I considered putting the code in the data or business layer, but opted not to because of the caching. How and what you cache seems to be more a function of the application rather than these other layers.
I'd be interested in other opinions and ideas that I may not have considered.
When faced with something that needs to be in the presentation layer of an asp.net web site or web application, but it also may have value in other asp.net web applications I find it useful to create a special class library that has a dependency on the system.web namespace.
Specifically, it will make use of HttpContext.Current to interoperate with the web site that is hosting the library. I'm not sure, but I generally think of this as a business layer assembly, but one that assumes it is hosted in a web context.
I keep my true business code (code that might be used in a non-web application) in a third assembly.
Having an assembly that depends on the web context allows you to use HttpContext.Current to find out what is going on with request and response objects as well as allowing you to interact with the asp.net cache API and related stuff. But it also keeps the code portable for use in more than one web application too.
Generally this web-dependent assembly is also where my HttpModules and HttpHandlers live too.
Keep in mind though that "layers" are logical concepts, not physical ones. There is nothing wrong with an assembly that contains business, DAL, and even presentation layer classes together. The classes themselves shouldn't mix up their roles, but a single assembly can contain classes from different logical layer in your design.
You could place it in your business layer and still use caching, either using the Enterprise Library Caching Application Block in the business layer, or by caching the value returned by the business layer in the ASP.Net cache in your presentation layer.
As it's coming from a different location to your other data I wouldn't put it in the same data access layer as the other database code.
I discussed this issue with some other developers at work and we decided that the presentation layer was the right place to do the translation. Consider the case where different applications that use the same business/data access layers want to translate the data in different ways. Unless we have a clearly defined business rule that states that individual identities shall always be displayed in a certain form, I think I'll leave it where it is and migrate it to a web controls library as needed to support multiple front-ends.