I an developing a web application in ASP.Net using C#, under .Net Framework 4.0. Now its time to implement payment page in that application. I am asked to provide the facility of every payment mechanism (pay-pal, credit card, visa card, master card etc.)
Now to be honest i even don't know the difference among these card type :(. Please guide me how to achieve this and if possible also suggest the tentative time for implementing this.
PayPal can take just about all of these types - why not just have them process everything?
Its hard to give you an answer of implementation time as I have no idea what your application is like - but its fairly easy to setup.
Here is a paypal for dummies link:
http://www.dummies.com/how-to/content/adding-paypal-to-your-web-site.html
Related
I know I´m late for this party.
Currently migrating form asp.net webforms to newer coding technologies and paradigms. Barely got started with asp.net mvc and now I´m noticing all this fuzz about mvc vs webapi. I'm an oldschool programmer and don´t really feel confortable with the "use both" approach, if there´s no need to. Please consider this:
My web projects focus on dynamic dashboards/admin sites to manage CRUD operations for tons of SQL records, generate reports on demand, statistics, etc.
No static websites at all (like info sites, portfolios and such).
Performance over UI design. Actually bootstrap basic UI is enough for me.
Pure ADO over entity framework, whenever possible.
Any tip or guidence on what I should choose would be very much appreciated.
* Edit/Closing *
Hi again and thank you for your feedback.
After a lot of reading and experimentation I´ve decided to give a real hard tryout to asp.net webapi + angular.js, mostly because I want to leave the door open for multiplatform/device usage (not web only).
Also, I found a very interesting article/tutorial in https://superdevelopment.com/2013/12/16/building-rich-web-apps-jquery-vs-angular-js/
It may be a little old but I think it´s worth reading, specially this extract right here: "Angular.js and WebAPI is a new way to build rich interactive web applications that fully embraces what can be done with a Web browser, JavaScript and C# rather than relying on out-dated paradigms that complicate the process for all but simple use cases. If your users and clients are expecting an application in a web browser that behaves like a native app on their desktop or smart phone, then jQuery + ASP.NET MVC is not the most straightforward way to build it."
Anyway, thanks to all and I hope this info helps others in the programming community.
if your application is going to be consumed various type of devices then prefer web api.
if your application is like website or portal where user has very little interaction then go for MVC
HI guys,
We always in our projects implement our own custom login by coding (login, recover, change,...), ASP.NET already have it, but the team leader always ask for a custom login.
I need someone to clarify to me as he is not arguable.
thanks
Simple - time, money, security.
Why spend time and money redesigning, implementing, testing and maintaining as system for which there is already a tested and mature infrastructure that doesn't cost a dime and is very easy to customize?
And consider the scope of the problem domain. There are hundreds of very diverse classes required to capably implement a robust security system. Do you really want to expend the effort to produce a system that is as secure?. There are thousands of man hours , end user feedback, testing etc to support the improvement of the asp.net providers.
What do you want to do? Use a session cookie? ;-)
Do you have people in your company with a better skills and experience as Microsoft has?
Has your company better understanding of ASP.NET, .NET and authentication problems as Microsoft has?
Has your company more financial and people resources and Microsoft has for ASP.NET development?
If you really has a form of Single-Sign-On implemented in your company or another not a solution using proprietary way, then you should describe this in your question. ASP.NET and WCF has a lot of customization possibilities. For example look as http://msdn.microsoft.com/en-us/magazine/ee335705.aspx about Using Active Directory Federation Services 2.0 in Identity Solutions. Other identity solutions are also possible.
You should not invest your energy in inventing of wheel or bicycle. Just use existing invention.
I need an opinion and advise from experienced ASP.NET people, what way to go.
Assuming that a developer has some practical background with HTML/JavaScript/PHP on one side and some .NET/C#/WPF experience on the other side. No previous hands on experience with ASP.NET - only theory and some read books on the topic.
The task is to build ASP.NET web site with User Managment functionality (user authentication, user account, user buying history, user points and so on) and E-commerce functionality with shopping cart, checkout and all needed for this.
Is it worth, i.e. will it be faster, more reliable and secure in the result to use a ASP.NET CMS system (for example Sitefinity from Telerik as declared developer friendly) to build such first site? In what case the learning curve will be more steep and it will take more time to achieve similar results?
Notes to take into consideration: 1) Price of the CMS matters not very much 2) E-commerce module should be written from scratch in any case (and integrated in case of using CMS) due to very specific requirements
It will be much faster to get an existing system. If you're going to have a shopping cart, then I would suggest you not even consider writing it yourself if this is your first foray into ASP.NET. The security and PCI Requirements alone will take you forever.
We recently got a new shopping cart for our web site and decided to purchase, and we're an experienced team. Our company used the AspDotNetStorefront, and we're pretty happy with it. You can use it for content management as well, and the price is good, but there are plenty of good alternatives out there.
Background:
I am an intermediate web app developer working on the .Net Platform. Most of my work has been defined pretty well for me by my peers or superiors and I have no problem following instructions and getting the job done.
The task at hand:
I was recently asked by an old friend to redo his web app from scratch. His app is extremely antiquated and he is getting overwhelmed by it breaking all the time. The app in question is an inventory / CRM application and currently each customer requires a new install of the app (usually accomplished by deploying it on a different domain on the same server and pointing to a new database).
Currently if any client wants any modifications to the forms such as additional fields, new features, etc my friend goes in and manually adds those fields to the forms, scripts, database etc. As a result all installs of this application are unique. There is no one singular source repository and no one single version of this app. Generally new features are overtime rolled into the other sites, but still this is done on an individual site by site basis.
I will be approaching this on a very modular basis. Initially I will be coding a module that will query an external web service for some data, display and store it, and periodically update it automatically. The next module will likely be for storing and displaying inventory data. This way I want to over time duplicate the current feature set of his app 100% but do it incrementally.
The Million Dollar Questions
I want to make the app have user
configurable form fields. The user
should be able to go to an admin
page, create a new forms page of a
certain category, and then specify
what fields he wants in there. He
could say 'create a new text field
called Item # and make it a
requirement" and that will get
stored somewhere. All forms will be
dynamically rendered to screen based
on what the user has configured. Is
this a good way to go about the
problem of having no idea what a
customer could want in a form? and
thus be able to store and display
form data of any sort ? What sort of
design pattern should I follow here?
I am familiar with asp.net and
the .net framework in general and
have decent knowledge of javascript,
html, silverlight, jquery, c# etc
etc. I can work my way around web
apps in a good way, but I am not
sure what sort of framework or tech
I should use to accomplish this
task. Would ASP.net 3.5 webforms be
the way to go? or should I look into
ASP.NET MVC? Do I use jquery and ajax for
complete decoupling of frontend and
backend ? or will a normal asp.net
page with some spattering of ajax
thrown in working with a codebehind
be the order of the day?
Just looking for general advice before I start.
I am currently thinking of using ASP.NET 3.5 webforms, jquery for clientside animation, ui, manipulation and data validation, and sqlserver + a .net or wcf webservice for backend.
Your advice is much appreciated as always.
I've recently implemented a white-label ecommerce system for an insurance company that allowed each partner to choose their own set of input fields, screens, and order the flow of the application to suit their individual needs.
Although it wasn't rocket science, it added complexity and increased development time.
Consider the user configuration aspect very carefully In hindsight both my client and their clients in turn, would have been happy with a more rigid system.
As for the tech side of your question, I developed my project in VS2005, using asp.net webforms and webservices with a SQLserver back end, so the stack that you're looking at is definitely capable of delivering a working product. ASP.net MVC will almost certainly help as far as testability goes.
The biggest thing I would change now if I was going to start again would be to replace the intermediate webservices with message based services using nServiceBus, MassTransit or the like. While the webservices worked fine, message based communication should be quicker and more reliable.
Finally, before you start to code, make sure that you understand the current system's functionality inside and out. If the new system doesn't do something that the old system did, it will be pretty obvious to the end users straight away.
I have a few projects coming up that have a number of endpoints or clients that can hit the same data. For instance a site might have...
A asp.net MVC based end user facing website
A web based adminitration back end that can allow specific, limited updates from some users in situatiosn where a full client isn't useful (mobile web etc)
A full on rich client for administration so we can use touch and other techniques to really make the user experience for content management shine - these may be silverlight or full on WPF apps, as needed
The question is... whats the best way to connect all that? Right now I use a multiple project split for the MVC.
ProjectName.Core - this project has all the common models, all the repository classes and all the helper classes
ProjectName.Web - an MVC project that references the Core to pull in the repositories and models it needs
ProjectName.Admin.Web - another MVC project dedicated to the admin interface that references the Core to pull in the repositories and models it needs
(which will ultimately live on a seperate subdomain from the end user facing site)
Then the story peters out int he sense of clear guidance. When the time comes to build a WPF / Silverlight project to hit the data I can do one of the following to the best of my understanding now...
Convert the "Core" to provide a RIA style DomainService, and attempt to alter the MVC projects to make use of it. However there is little guidance on using MVC with RIA, RIA is in its infancy AND the WPF to RIA story is also still only thinly documented
Do the same as above, but using WCF. However WCF prings with it async complexity that I really want RIA to hide for me.
Fall back 20 yards and just bolt plain old web services onto the Core on top of the Repositories and Models I already have. This seems... old school :)
Any thoughs and input are welcome including pointers to examples and documentation. I want to make the best decisions I can now, and am coming up to speed fast on RIA and WCF so I can but community input is always helpful.
Thanks!
Take a look at ADO.NET Data Services (formerly known as Project “Astoria”).
On my way to work today I was listening to a .NET Rocks! podcast, "Stephen Forte on Data Access Options", and they very excited about this, especially for scenarios like the one you describe.
It's interesting stuff, and something I would check out sometime very soon.
I think there's something to be said about plain old WCF services, these can make use of your domain services and repositories and expose a model more appropriate for services. Too often I've found that simply exposing the domain model on the wire ends up with a duplication of logic on both the client and the server.
My advice would be for some sort of service layer, this has the logic of shaping your domain model into appropriate types for the wire. \
Ideally I'd like to be able to share my Domain Services between the client (WPF / Silverlight) and the server (ASP.NET MVC) and have different underlaying repositories (Linq to NHibernate / Astoria). Difficult with the asynchonous nature of Silverlight.
For the curious, it certainly looks like RIA Services is the win here. Build a single DomainService then consume it everywhere. Brad Abrams covers a lot of this ground at bit.ly/94fFx - it really helped.