Our Oracle application is written in Oracle Forms. However, there is a requirement for it to be a Rich Internet Application (RIA). I.e. no deployment, accessed via web, looks and navigates (tabbing etc) as closely to a desktop GUI application as possible.
Apex has been discarded as not good enough and will not produce a sufficiently good user experience and does not look good compared to other technologies.
Silverlight is being suggested as the best way forward, but I would like to know what else is out there.
I have had suggestions that the way forward is to use HTML5/CSS, but we need a good framework for managing records. I do not wish to be reinventing the wheel. I understand that Silverlight for Business Applications takes care of some of those requirements.
Also, the idea is to create web services in Oracle and have a Silverlight front-end. Is this possible / the right way of doing things?
Any pointers in the right direction or thoughts would be appreciated.
Thanks.
Apex has been discarded as not good
enough and will not produce a
sufficiently good user experience and
does not look good compared to other
technologies.
Oracle Apex has all the features that you are looking for. You can customize it using CSS, users can access it using web and since your current application is in Oracle Forms, you can reuse a lot of your code written in Oracle procedures/packages/triggers. Also, the learning curve for your Oracle Developers would be very smooth.
I'd suggest you to try and create a small module for your future project and see how effective it is in terms of both Development time and the rich UI.
I don't know much about it, but you might want to look at FormSpider.
And of course there is Oracle ADF.
Like Rajesh, I bridle at the suggestion that Apex is "not good enough", having been heavily involved in a very successful Apex project ;-)
From my point of view,there is no direct dependence between your future RIA's and the RDBMS you are using now. In other words,features and advantages of Silverlight\Entity Framework are almost equal for different data sources (e.g SQL Server,Oracle and etc).
Also, the idea is to create web
services in Oracle and have a
Silverlight front-end. Is this
possible / the right way of doing
things?
Using a middle tier (WCF or WCF RIA Services) as a data access layer will be more preferable than creating web-services in Oracle.
This tutorial can be usefull for you to get some general view of the Silverlight and WCF Ria Services.
http://www.silverlightshow.net/items/WCF-RIA-Services-Part-1-Getting-Started.aspx
Related
I am after recommendations for a framework (or project template) for rapid application development using C# on the back-end. It must support the following:
User login/authentication
SPA
Responsive client
Easy to understand client and server (not a steep learning curve like AngularJS)
Clean/uncluttered project structure (both client and server). Some OOTB ASP.Net project templates are very cluttered (eg the the VS2012/2013 SPA MVC/Knockout/BackBone template) - maybe I could be convinced, but just looking at a new project it puts me off instantly.
Easy DB access.
Flexibility on the client (for custom functionality eg adding maps and other UI libraries like D3) - don't want a client framework that you have to wrangle to paint outside the lines.
Would appreciate any/all suggestions/opinions.
Thanks
Tim
Like anything in software, there are so many ways to do this. You are essentially asking for a complete system architecture. You could try to be more specific, but your question is going gather opinionated answers and this will probably end up getting closed.
But I'm bored and will throwin a couple of pennies before that happens:
C# most likely means you'll be going .NET on IIS (though maybe its docker on linux?? refer back to my first line above)
User login/authentication
If its IIS, you could be running Windows Auth, or if in an enterprise, Kerberos or Federation. Or if its going against social sites, maybe OAuth? This one depends on what authentication your users need and is really separate of the other areas below.
SPA / Responsive client / Easy to understand...
You listed some very popular frameworks (Angular/Knockout) used in modern SPAs. You may not like them but these are becoming industry standards. Responsive web is pretty much bootstrap or foundation. Though, angular material seems to be gaining popularity too.
Easy DB access.
Whats your definition of easy? Looking for an ORM? If so, Entity Framework is popular in .net apps. Or if you are more of an SQL person, maybe LINQ is easier. Many options here too.
Flexibility on the client ...
Though you may not like some of them, using popular frameworks means you get a lot of developer support behind it - and a lot more answers here on SO if you have problems. One man's sunset is another man's sunrise. What you consider difficult might be viewed as easy by another. Hard to say whats most flexible but going popular means you got more help.
I'm the custodian of a pretty sophisticated, yet antiquated, ASP.NET application. It is essentially a platform that makes creating database applications easier - with tools to read in database schemas, auto generate forms, reports, charts, and provide extremely extensive tools to manipulate those things within the UI. There are some pretty big clients using the platform for some niche applications, and despite the age of much of the code (some of it written as early as 2001), everything runs pretty well.
The company is doing well enough that i need to start considering a new version, and rather than plastering on some new features, i'd like to consider a fresh start. The current solution is a ridiculous 150 projects - down from about 220 when i first started working on this full time.
Does anyone have any tips or suggestions for the general structure of an enterprise(ish) level application? What new technologies should i consider? Maybe some particular books or websites i should review?
I've got a good handle on all of the specifics that make our platform so flexible - but because i've been locked into the general structure of our code for so long, i feel like i'm way out of touch with how the entire thing needs to be structured on a large scale. The current application still has a bunch of .NET Remoting for communication with the databases (just a tad out of date), and a ton of incredibly inefficient code written by someone who wasn't really a programmer.
WCF to serve info from the data access layer? WIF to authenticate? I'd really like to be able to assemble an API that my business partners can use to connect to the data and use a huge collection of common functions i've got set up - ideally that API could run in a web context or in some other environment.
I know this is a pretty big question that could have a lot of possible answers - just looking for some thoughts on where to really spend our research time.
Thanks!
-RP
If you want to rid yourself of all the authentication / authorization hassles, absolutely go for claims-based applications, WIF, ADFS etc.
That's the Microsoft direction - CMS, SP. Office 365. Windows Azure AD etc. are all now claims-based.
Only problem is that ADFS authenticates against AD. Have a look at Identity Server for something DB related.
Plus ADFS via ACS provides Facebook, Google etc. logons.
There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have around 4 years experience of ASP.NET & SQL Server (only web forms). I have a little knowledge of Ruby on Rails and have developed one very small 2-3 pages application in ASP.NET MVC in my job. Now I and one of my friend ( same experience like me) are willing to gain more experience of ASP.NET MVC. For that purpose we have thought of developing an open source application in ASP.NET MVC. It can be a a blog system or forum or anything else so that community can also take benefit of it. But we are not able to decide the back-end database for the application between MySQL and SQL Server. What will you suggest in terms of following -
Which will be more supported or required by community?
If we use MySQL, will it be a tough road ahead?
Is there any chance of supporting both by using ORM (I have no experience of working with any ORM)
Any other suggestion ?
Thanks in advance.
If you can't decide which to use as a backend, then one suggestion I have it define an interface for the data layer, use the IRepository pattern against this interface, and simply pick one and write an implementation of the data layer for that choice. In a (successful) open source project, it's unlikely that everyone who wants to use it will have the same ideas about what database will work for them. In that case, designing it so that it can use any database, given a suitable implementation of the interface is a wise move. Using something like nHibernate, which already supports many different databases may be the route you want to go if you don't mind having dependencies on other libraries.
Which will be more supported or required by community?
For most business users, and most dedicated ASP hosting providers, it will be Microsoft SQL Server IMHO. With a surprising spread across version numbers. I see quite many SQL Server 2008, a lot of 2005, and quite surprisingly many 2000's too.
For small "we're cheap, is it gratis?" businesses and individuals, I do see some MySQL on Windows too. I guess in my little circle of companies that I've worked with, it is 2/3 MSSQL and 1/3 MySQL of the two databases you mention.
If we use MySQL, will it be a tough road ahead?
In terms of more difficult development? Yes and no; LINQ to SQL is more or less only available for MSSQL, and many find it to be a simple and natural technology to work with. So "yes" if your plan was to use LINQ to SQL as your ORM of choice. Other good ORM's like nHibernate work equally well with both databases, as elder_george says.
Is there any chance of supporting both by using ORM (I have no experience of working with any ORM)
Sure, f.x. with nHibernate, and a bit of extra XML for nHibernate configuration, and some more extensive install docs, SQL scripts et cetera for the users.
Any other suggestion ?
Since this is your first application, play around with the design first using mocksups & prototyping, UML or something else of your choice. See if you can get some experienced MVC developers to critique your design, but don't take their critique as gospel, there is more than one way of doing things right.
Definitely consider tvanfosson's suggestion to use an IRepository to provide flexibility on the storage layer.
Consider using unit testing and dependency injection from the start too; both are IMHO very important and helpful in the longer run. On the downside, that would be a lot of new technology if you don't have prior experience with these.
MS SQL is easier to use with .NET. .NET includes LINQ to SQL ORM out-of-box, so nothing has to be installed.
MS SQL has a free Express edition but it's up to you to decide whether its capabilities (4Gb for DB, 1 CPU only and so on) will be enough for your application (IMHO they will be =))
There'are ORMs that allows to switch between DBMS's: NHibernate, SubSonic, DbLinq. NHibernate is the strongest beast out there, and it has an active record implementation built if you are looking for familiar concepts from RoR.
tvanfosson and elder_george had given good comments.
ASP.NET MVC aside, it's more of MySQL vs MSSQL. I've developed web projects using both and find them relatively on-par from a development point of view. ORM I've used is NHibernate.
From deployment/production perspective, you will be bounded by MSSQL Express edition's limitation, assuming you are not going to pay for it. You might want to spend some thoughts in this aspect.
Use ORM -> NHibernate
https://www.hibernate.org/361.html
I was in a similar situation a couple of months ago. Now my newest project on ASP.Net MVC is almost complete. Here's the set I chose
--ASP.Net MVC + MySQL. No ORM.--
I decided to go with MySQL instead of MS SQL because MySQL is free, and MS SQL is very expensive. If you're making an open source application, you gotta think about that seriously. This is going to be a major problem if you are targeting widespread adoption of your application.
At first I tried to use MySQL through an ORM -- Enterprise Framework (EF). It was the worst decision ever. Enterprise Framework totally killed the performance. It was the pits of the pits. I believe nHibernate is better, but I don't know how much better.
With my own SQL code things are fast enough.
The first iteration of my site will be in public beta this week and then there will be several iterations.
It went rather well so I car recommend the set I chose with ease.
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.