It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
As far as my understanding goes Modules kann be used to split an Application into different parts.
A big advantage seems to be to be able to load Module after Application Start, to get a better Startup performance.
I personally would like Modules to make me able to have an own Code Sandbox for the Module Code.
So neither the Main App Code nor the Module Code should influence each other. But for examples CSS Styles from modules influence the Main Application an visa vers.
My Question:
1. What can I use Modules for beside Runtimeloading ?
2. Are there options to run code in an own sandbox ? For Example via Loading swf assets ?
What can I use Modules for beside runtime loading ?
You can divide your application into distinct pieces - For example, you may only need to update the shopping cart portion of an application rather than the entire application. This lets you do that without deploying the entire application again. This forces good abstraction and means less regression testing / bugs.
Another benefit is securing the swf files themselves. I've written back end applications where a user might be able to get to the orders screen, but not the user management screen. Because each are a modules, the client never even gets an opportunity to see (or decompile) the user management swf code - because I can validate the user's session server side when they try to load a module. This is an extra layer of protection.
Memory management -its not just about loading the application, but how much processing it takes to have all that functionality loaded at once. If a user only needs one or two screens, why load the other 98 screens?
Portability and code reuse. You might use the "order viewer" module in both a consumer facing application and a back end tool. Those are most definitely not the same application, but they both need the basic functionality of the order viewer. Better yet, an entirely different application could use that same functionality.
Are there options to run code in an own sandbox ? For Example via
Loading swf assets ?
There are special considerations for communicating between modules, here is a good read for you:
http://livedocs.adobe.com/flex/3/html/help.html?content=modular_2.html
You can allow a module to deal separately with its styles by creating a new SystemManager for its flexModuleFactory, and you can load it into a separate applicationDomain for security purposes.
Not really an answer to the question you asked, but it addresses the underlying problems you were having.
We used modules at my last job to allow us to develop and add new functionailty on the fly--the path to the module would be stored in a database and loaded at runtime.
HTH;
Amy
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I need to know the technical difference of those files. Which one is the best option?
When and why should we use it?
I need a human answer, not the MSDN links.
.ashx files are used for handling HttpRequests and modifying HttpResponses; you can pretty much make them do whatever you want. I have seen them used for things like serving PDFs and doing server-side processing and then redirecting. See here for more info.
.svc files (which were not mentioned in your question) are part of MS's new Windows Communication Foundation which is for SOA development. WCF supports SOAP, REST and a lot of other cool stuff.
.asmx files are an older means to host SOAP services. They are often accompanied by asmx.cs files (or .vb) which contain the actual methods behind the service. See here for more info. This is a legacy technology and I would recommend using WCF instead in new development.
[WebMethod] attribute is used to denote the methods surfaced in a SOAP service hosted by an asmx. See here for more info.
The .axd extension is used by generated web services used for many different things. (E.g. MVC3 uses axd web services to serve MS specific javascript) I don't think you would ever create an axd file, but I could be wrong... at least I never have. See here for more info.
Which one is the best option?
They are different tools used to solve different problems. When and why you should use each one depends on the job you are trying to accomplish. Lower level handling of your web application's behaviours can be achieved with ashx files. If you want to provide more standardized services, I would recommend using WCF and svc files. Please provide us with more information about the task you are doing so we can help you pick one.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
we have centralized back office system and we keep all products information,recently our clients asked us to deploy website to them, so they can show their products on their websites , the clients have their own websites which developed on php or java or whatever , they don't like to use Iframe to show their products because of some SEO problems in Iframe, We want to deploy our E-commerce website inside their website,We want to show our website inside HTML tag such as div,we don't like to design and develop new website for any individual client, I am very interested to know your ideas , and any alternative solution.
So instead of focusing on developing a website that is embeddable, I would focus on one of two approaches: 1) Make web services/REST API, 2) Write a Javascript library.
Making a REST API
You can write web services (or a REST API) that a client could use to integrate into their site. This would expose your data/services/features to them. They would have to do a little programming of course to integrate with the services, but it's an option.
Writing a Javascript library
You can write a Javascript library that will dynamically bring in data (calling web services of course that you host) and then you can take that data and place them into divs etc.
The advantage of this is that you can tell the client something like "just drop these 5 lines of code onto your page and it will do the rest." It has a low barrier to entry for a client.
This question already has answers here:
ASP.NET Web Site or ASP.NET Web Application?
(25 answers)
Closed 9 years ago.
I've read a lot of discussions about web site vs web applications in asp.net
The way we work in my team (10 programmers), we use the project type "web site", and for our dev environment, we just copy the source code (aspx + .cs) to the server. This way, all the programmers can be doing changes at the same time.. and the server does the build dynamically. .....(for the prod environment, they build the application)
Now, I'm starting a new project, and I decided to use web application (the main reason was the web config transform option).. I soon realized that (as far as I know) it forces you to do a build/publish of the web app to the server with every change... which is not a big problem if I'm the only one working on this project...
But, now I'm wondering, what's going to happen if more programmers needs to work on this new project at the same time?
Any advise or similar situation?
EDIT
we're using Visual Source Safe... but only for keeping track of the older versions (not for builds)... I'm familiar with Subversion... but.. unfortunately, I don't take the decision on what we should use.. and I don't think they're willing to change
Thanks everyone for your answers...
Anytime I hear the, this isn't a big problem as long as. . . . immediately tells me, that I should assume that it will be a problem. In short, go with what you know. If you are familiar with using the ASP.NET website, then I would use that. Your development practices are already focused around handling that.
This is the same model that I used when doing classic ASP when I first started programming at a company. This model works, although I would strongly suggest getting source control too. That being said, here is what I would do long term:
Source control
Develop locally
Get a continous build process going (cruise control is a free one).
Have one person push everyone's changes to the development server, once everyone agrees that all the changes are compatible with each other. (normally this is done by making sure the build server can compile everything).
If you choose to use web application and add more programmers on the project, I recommend using source control. Git and Subversion are very popular. In Git, for example, you can see who commits what.
Of course, I would use source control from the get-go, whether you're on your own or collaborating with a group.
As #edmastermind29 said source control is really the #1 thing to keep that straight if you are having more then 1 developer.
It really depends on your development process. Most shops do some type of continuous integration and have unit tests running and have some sort of automated build process.
I have found that using a web application project is really the best for all the "best practice" types of things.
Check out this link for some guidance.
It really depends on how your team works, and how your environment is configured. Regardless though, you need to have some sort of source control system in place to ensure that your not overwriting each other's changes. If you don't already have a source control system in place, stop now and get one immediately.
Depending on which source control system you choose, you will at least have the basic checkin/checkout features that serve as a library for your code base; meaning if I have a file checked out you can't touch it until I've checked it back in.
If you choose a more feature-rich source control system, you should be able to take advantage of features like branching and shelving, which will allow your team to work on the same files simultaneously, and merge the changes when the files are checked in.
While your question is about web sites vs. web applications, the answer is source control. With a good source control system in place, your question becomes more or less irrelevant, aside from needing to coordinate builds with a web application.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Back in 2006 I've created a web site using asp.net 2.0. At that time, I had used Web Forms and classic ADO.NET SQL queries to connect to the underlying database. I've also used a fair amount of XSLT.
Today, the site still stands (it has gone through various upgrades but it is still based on Web Forms and simple SQL queries) but I believe it really needs to be upgraded as far as its technological infrastructure is concerned.
What is the next step I should take to move forward? A bit of ajax? JQuery maybe? Rewrite it in asp.net mvc? Replace SQL with typed datasets or even ling to sql? And what is the best way to embrace APIs such as twitter's?
So, can an old dog learn new tricks?
So why do you believe the site's infrastructure needs to be upgraded? If the site is running and performing well after 6 years of load and data, then what factors are causing you to think you need to upgrade it?
Are there features that you want to implement (or users are asking for) that you can't implement with the current infrastructure?
Is maintenance difficult and brittle, and every time you upgrade, you spend weeks fixing bugs introduced?
Are there integrations that you'd like users to be able to do so that they can extend your application's functionality and/or data to their own applications?
Those reasons above could be reasons to upgrade, but I can't really tell you.
But as far as some of your questions about what to upgrade:
a bit of AJAX? It depends on what your current infrastructure looks like, but it's not too hard to introduce and you can isolate it
pretty well with a service layer.
jQuery? Again, it depends on
how your pages are structured. If you have a lot of master page
re-written IDs and very few classes on your DOM elements, using
jQuery right off the bat may be tough as you'll have to figure out
how to get your selectors in line.
Replace SQL with Typed
DataSets? Please don't do that. Honestly, if you go with
Linq-to-SQL or EF, you'll probably take a slight performance hit
compared to using ADO.NET with DataReaders (if that's what you're
using).
Can an old dog learn new tricks? Always. The learning
never stops.
I would just advise not to upgrade just to upgrade. Make sure you have legitimate business reasons for doing so.
Hope this helps. Good luck!
Step 1) figure out what would add value for your users
Step 2) investigate technical solutions to solving those problems
Step 3) learn and build
You could create a persistence layer and learn about entities. This is an extremely useful skill to have. You could do this by using NHibernate. I would also throw in some LINQ to get a great combo. After this i would probably go to the GUI and do some needed features with jQuery
We need the ability to send out automatic emails when certain dates occur or when some business conditions are met. We are setting up this system to work with an existing ASP.NET website. I've had a chat with one of the other devs here and had a discussion of some of the issues.
Things to note:
All the information we need is already modelled in the ASP.NET website
There is some business-logic that is required for the email generation which is also in the website already
We decided that the ideal solution was to have a separate executable that is scheduled to run overnight and do the processing and emailing. This solution has 2 main problems:
If the website was updated (business logic or model) but the executable was accidentally missed then the executable could stop sending emails, or worse, be sending them based on outdated logic.
We are hoping to use something like this to use UserControls to template the emails, which I don't believe is possible outside of an ASP.NET website
The first problem could have been avoided with build and deployment scripts (which we're looking into at the moment anyway), but I don't think we can get around the second problem.
So the solution we decided on is to have an ASP.NET page that is called regularly by SSIS and to have that do a set amount of processing (say 30 seconds) and then return. I know an ASP.NET page is not the ideal place to be doing this kind of processing but this seems to best meet our requirements. We considered spawning a new thread (not from the worker pool) to do the processing but decided that if we did that we couldn't use the page returned to signify a success or failure. By processing within the page's life-cycle we can use the page content to give an indication of how the processing went.
So the question is:
Are there any technical problems we might have with this set-up?
Obviously if you have tried something like this any reports of success/failure will be appreciated. As will suggestions of alternative set-ups.
Cheers,
Don't use the asp.net thread to do this. If the site is generating some information that you need in order to create or trigger the email-send then have the site write some information to a file or database.
Create a Windows service or scheduled process that collects the information it needs from that file or db and run the email sending process on a completely seperate process/thread.
What you want to avoid is crashing your site or crashing your emailer due to limitations within the process handler. Based on your use of the word "bulk" in the question title, the two need to be independent of each other.
I think you should be fine. We use the similar approach in our company for several years and don’t get a lot of problems. Sometimes it takes over an hour to finish the process. Recently we moved the second thread (as you said) to a separate server.
Having the emailer and the website coupled together can work, but it isn't really a good design and will be more maintenance for you in the long run. You can get around the problems you state by doing a few things.
Move the common business logic to a web service or common library. Both your website and your executable/WCF service can consume it, and it centralizes the logic. If you're copying and pasting code, you know there's something wrong ;)
If you need a template mailer, it is possible to invoke ASP.Net classes to create pages for you dynamically (see the BuildManager class, and blog posts like this one. If the mailer doesn't rely on Page events (which it doesn't seem to), there shouldn't be any problem for your executable to load a Page class from your website assembly, build it dynamically, and fill in the content.
This obviously represents a significant amount of work, but would lead to a more scalable solution for you.
Sounds like you should be creating a worker thread to do that job.
Maybe you should look at something like https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
You can and should build your message body (templated message body) within domain logic (it means your asp.net application) when some business conditions are met and send it to external service which should only send your messages. All messages will have proper informations.
For "when certain dates occur" scenario you can use simple solution for background tasks (look at Craig answer) and do the same as above: parse template, build message and fast send to specified service.
Of course you should do this safe then app pool restarts does not breaks your tasks.