What would be the pros and cons of taking a large (16000 LOC) existing Access 2007/Forms application and porting it to SQL Server 2005, while keeping the Access forms on the front end, versus porting the front end to a .NET technology, say ASP.NET 4.0 or MVC3? The backend is definitely getting ported to SQL Server, with large schema modifications, so this question is about whether to use the existing Access Forms front end or not. I don't take throwing away existing working code lightly! On the other hand, the schema will be changing a lot.
If you had a lot of experience with ASP.NET/Oracle but not with Access or SQL Server, how might this change your answer?
Thanks,
Mike
There is nothing wrong with Access as a front-end to an RDBMS whether SQL Server or another
Porting the front-end but leaving an Access back-end would seem a bit weird: why bother? Access is a good presentation tool but mediocre DBMS. Why keep the mediocre?
Also, only change one component at once no matter what you do: data, then front end. Don't do a big bang approach and change the lot
Actually, comparing going with web application (ASP.NET) and stand-alone (Access) is not truly "apples-to-apples" comparison. It highly depends on your requirements.
Sure, going with web application will require much more developer's efforts comparing to building forms/reports in Access. But, the pay-off will be felt in the mid to long term.
You should also consider scalability, deployment, and availability issues when deciding to go/stay with Access.
Related
I have been getting a bit lost in the creation of my program architecture and I want to take a step back to see if I'm approaching it correctly.
I am wondering if my setup makes sense. I'm starting to think it doesn't.
I am creating intranet applications (We were creating Internet applications, but now the scope has changed). We use an onsite Active Directory (Windows Server 2012 R2). We have a SQL Server Database.
I have been building Front End Angular applications and ASP.NET Web API's to push and pull data. I am now implementing Authentication with Auth0 and it's been a nightmare.
What kind of program architecture would you setup in this scenario?
Much Appreciated.
SQL Server + Asp.Net Web Api + Angular JS forms a perfect architecture for building Single Page Applications (SPAs). This architecture is useful for building desktop like web applications, i.e. apps that runs over web but works like desktop apps.
If you can be more specific about the problem you are facing, you will be able to get better recommendations from so.
This architecture is widely adopted in many scenarios such as SPAs. With it, you will be able to keep your front-end highly decoupled from your backend services being able to support multiple front-ends on the same set of services and run quite a few integration scenarios.
Some of the downsides of such an approach will be the extra layer of complexity added to the application (which might force you to write more tests and handle different failure scenarios that wouldn't happen otherwise, for an example) and authentication routines since you will need to authenticate two heterogeneous environments (the .NET/IIS one and the JS/Angular one).
As for the authentication pain, token-based auth schemes seem the current way to go (such as Auth0) since they let you keep and send an environment-agnostic token which will be used by different layers of your architecture.
In that sense, your architecture makes sense.
However, since you're feeling some pain in its implementation, you might want to ask yourself if you really needed all of these. When you choose an architecture, you do so trying to accomplish some specific goals (multiple front-ends? specific performance requirements? maintainability? auditability?) and the more goals you try to accommodate in your architecture the more complex will become up to a point where the pains start outweighing the benefits.
So, what were you trying to achieve in the first place?
I'm running a large classic-asp site (self-developed) for a public library (25k users) which actually performs really good (oracle 11g r2 database), but from time to time new services need to be added or old ones adapted.
And there's my dilemma. Every time I work on this site I feel like I should not update this outdated monster no more and that I should port it to a up to date technology. But how to start? I have good knowledge in developing asp.net (vb.net) websites and I’m searching for a way to rewrite code in .net (Webforms, MVC, WebApi, ... ?) and integrate it part by part into the classic asp site, (I can't rewrite the whole thing at once, because I haven't enough time!) so that some time from now on the site will be completely rewritten.
Another thing I need to consider is the Oracle DB and the already existing and optimized (and often oracle specific) SQL statements that I definitely want to use in the new built (so entity framework and linq seems not an option).
I was thinking about using the new WebApi and call the actions via jQuery from the classic asp site, but couldn't find an easy way to interact it with ODP (returning and accepting Json).
I'm really hoping for anyone to point me into the right direction!
If possible you will need to break your existing website into modules can be separated out and rewritten individually.
Because you are doing such a massive rework between an outdated technology (classic ASP) and bleeding edge (WebAPI etc), it probably won't be possible to run the two as a single application. You will instead have to run two separate applications side by side which will behave as a single application for the user. Part by part you will move your separated modules from the old application to the new.
If you want to continue using Oracle, it's still possible to use Linq and Entity Framework as these are used for querying your data rather than actually storing it. You can use Oracle, MSSQL or even one of the newer document databases such as Mongo or Raven DB.
I am taking part in Imagine Cup and got only three months for building a site in ASP.NET. Is it possible to learn enough to build a working site containing an cms, login system in a month. Its not that I am beginning web development, I already know a little asp.net and know AJAX, JAVASCRIPT, CSS, HTML, SQL but have never worked with databases. I was never into web development but started because of Imagine cup. In 2 months I already know HTML, CSS, JAVASCRIPT, HTML and AJAX but I am worried about the complexity of server-side scripting and ask for the best way to get me working in ASP.NET in a month. I know c#.
Although you can't be an expert in a month, you can get up and running fairly quickly with webforms. Since it already includes a login system, you can get that up and running quickly.
As far as CMS, it depends what you need. An advanced CMS system is a major undertaking.
Getting going with ASP.NET
Actually, if you want to re-apply everything you know about creating JS enabled static html sites, you'd have a smoother path using MVC because you don't have to guess what the tag id's are, you don't have to guess what kind of HTML a server side control is going to create, etc.
That said, Jonathan Wood is correct, to just create a page with labels and buttons, Web Forms has fewer concepts you need to learn, but you will find it harder to apply the same techniques that work well with JS + static html.
Data bases
If you use SQL Compact, then it is easier to get started because you needn't learn to mess with the numerous things going on with SQL Server (like a security model appropriate for big companies, but not for learners). Another easy alternative is MS-Access because the "Query by Example (QBE)" query designer is still better than anything that the Visual Studio or SSMS teams ever put together.
Keep in mind that if you use MS-Access, while it will be really easy to learn (more so than SQL Compact), MS-Access uses Jet SQL and has many other differences from SQL Server, where as everything you learn about SQL Compact will apply to SQL Server.
Not sure what the conditions etc of Imagine cup are, but I strongly recommend to use an existing CMS (in particular Umbraco) instead of developing all from scratch. Some advantages are:
No need to dive into SQL and databases right away
Building blocks are available (login system) and leverage existing ASP.NET technologies
Razor can be used instead of xslt which will be a skill you'll be able to apply to pure ASP.NET MVC development later on
Very friendly and helpful community if you need some help
Starter kits available - basic web sites can be created easily
By diving into any detail of the CMS, you'll learn a lot (source code available)
You could probably pick up the basics with a few good books. Sam's, Wrox, APress and O'Reilly are great. You can also check http://www.asp.net/get-started for Microsoft's official tutorials.
You can also download the express versions of Visual Studio 2010 and SQL Server. If you want to continue on after the competition I'd strongly recommend you learn database programming on SQL Server 2010 Express. (It'll help you down the road)
Good luck with it.
My company has a fairly old fat client application written in Delphi. We are very interested in replacing it with a shiny new web application. This will make maintenance a breeze and many clients want a web application.
The application is extremely rich in domain knowledge, some of which is out of our control. Our clients use the program to manage their own clients and report them to the government. So an inaccurate program is a pretty big thing. The old program has no tests. We are not sure yet if we will implement automated testing with the new one.
We first planned to basically start from scratch. But we are short handed and wanting to basically get everyone on the web as soon as possible. So instead of starting from scratch we've decided to try to make use of the legacy fat-client database.
The database is SQL Server and can be used in SQL Server 2008 easily. It is very rich in stored procedures, functions, a few triggers, and lots of tables with over 80 columns... But it is decently normalized. We want for both the web application and fat client to be capable of using the same database. This is so that if something breaks badly in the web application, our clients can still use the fat client and connect to our servers. After the web application is considered "stable", we'd deprecate the fat client.
Has anyone else done this? What tips can you give? We want to, after getting everyone on the website, to slowly change the database structure to take care of some design deficiencies. What is the best way to keep this in a data access layer so that later changes are easy?
And what about actually making the screens? Is there any way easier than just rewriting an 80 field form in ASP.Net? Are there any tools that can make this easier?
The current plan is to use ASP.Net WebForms (.Net 3.5). I'd really like to use MVC, but no one on the team knows it including me.
We are not sure yet if we will implement automated testing with the
new one.
Implement automated testing. What's the point in replacing one buggy program with another?
Good question, but "Slowly change" the db structure after getting everyone on the website, sounds like a joke...
I would rather take the opportunity to create a fresh db structure, write a bulletproof migration script for you db, that you can try out and rewrite a zillion times without any side effect fro your clients, and then write whaterver you want (fat/web) on the new db, have it tested and migrate everyone when it's ready.
I have a couple suggestions:
1) create a service layer to abstract away the dependance on the DAL. In a situation as you describe having a layer of indirection for the UI and BLL to rely on makes DB changes much safer.
2) Create automated tests (both unit and integration), especially if you plan on making fairly significant changes to the Domain or Persistance layers (BLL/DAL). To make this really easy you should always try to program to an interface. This makes your code more flexible as well as letting you use mocking frameworks (Moq is one I like) to ensure your tests truely are unit tests and not integration tests.
3) Take a look at DDD (http://domaindrivendesign.org/) as it seems to fit pretty well with the given scenario. At the very least there are some very useful patterns that can help make your application more flexible.
4) MVC isnt very hard to learn at all, it is however an easy way to get unit testing setup for the UI as a result of the MVC architecture (testing the controller and not the view). That said, there is no reason you couldn't unit test web forms, its just a bit more work. MVC really is just a UI framework/design pattern (more Model2 but we can ignore that for now). It gets you closer to the metal so to speak as you will be writting a lot more HTML and using a Model (the 'M') for passing data around.
For DDD take a look at Eric Evans book: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1
Hope that helps
ASP.NEt forms is a no starter, is completely inappropriate for something like this. I recommend to start with something like Creating an OData API for StackOverflow including XML and JSON in 30 minutes, then build your Web app on top of that (ie. push it to the client, use JQuery/Silverlight).
The current application is a kind of CRM application built upon MS Access. The application is for internal use. My job is to migrate it to ASP.NET web-based application. Now boss requires to keep Access as database and develop ASP.NET code against it.
My question is, is there any disadvantages of using Access as database in ASP.NET application? (e.g. optimistic concurrency issue?) Should I persuade boss to upgrade Access to MS-SQL?
Many thanks!
We've used Access as a backend for web sites with good success. It's cheap, can be used effectively by moderately skilled programmers, and you can store the MDB on a document server so it gets backed up.
Most IT people dislike Access, but from a business perspective, Access can be very valuable.
MS Access is notoriously unstable in multiuser environments. A WEB app is by definition heavily multi-user.
So IMHO leaving MS Access as underlying DB is a call for trouble. At least use SQL Express (it is free)
The problem you are going to face in upgrading from Access to MS-SQL is that there is a major cost investment for the application. If your company already has the infrastructure in place(licensing, hardware...) then you won't have such a hard fight to pursuade your boss.
As for a technical answer:
I'd say you need to let you boss know that access databases aren't ideal for concurrent usage which a web application suggests is the intended goal of the application. My view is that Access is for database information that a SMALL set of users will be simply using for small data entry and querying. NEVER use Access to build an enterprise-level solution.
If you are planning to upgrade a Microsoft Access database to SQL Server 2008, use the SQL Server Migration Assistant (SSMA) rather than the upsizing wizard built into MS
10+ tips for upsizing an Access database to SQL ServerAccess.
Your boss probably likes to do ad-hoc stuff with access / excel. If you move the DB to SQL Server Express you can use Access and it's linked table feature to let your boss keep doing his ad-hoc needs through Access while keeping the data in SQL Server Express. If you keep the linked tables named the same as the old physical ones all his reports and queries will should keep working.
I'm an Access promoter, but not for use on websites because Jet/ACE is not threadsafe (though Michael Kaplan once said that is is threadsafe if you access it via ADO/OLEDB; I don't quite understand how a database abstraction layer can wash away a characteristic of the underlying database engine it's calling, but if MichKa said, it's 99% likely to be true).
Now, the exceptions would be if you're using it for prototyping something that will use a different database, or if it's read-only, or is read-write but will only ever have a very small number of users.
Michael Kaplan's website, trigeminal.com, used to use a Jet database as the back end (it may still -- I don't know that MichKa ever changed it), and when that was his main website he reported getting 100K hits a day. But it's a read-only site, so fits my restrictions.
There are so many different alternatives and they are mostly easy to use that I just don't see the point of trying to use Jet/ACE as back end for a website. I'd never do it myself (all the websites I'm responsible for use MySQL).
Simply put, go with MSSQL. Express edition is free, and will give you everything you need to migrate away from Access. These articles are talking about Access applications specifically, but the same issues will plague you.
http://resources.zdnet.co.uk/articles/features/0,1000002000,39285074,00.htm
https://web.archive.org/web/1/http://techrepublic%2ecom%2ecom/5208-6230-0.html?forumID=102&threadID=205509&messageID=2136367