we need to develop a web application using Oracle ADF and jdeveloper 12c. we have 10 modules. Which architecture pattern is best approach in the below 2 patterns.
1. Sum of Parts.
2. Cylinder .
Or is there any other patterns for Production Project.
I work 3 years on ADF framework (11.1.1.7 - 11.1.1.9) and familiar with 12c; There have been a lot of changes that make work easier than before!
I suggest develop modular system and use every module in a base application (present last view to end user), this help you to keep agile development; You can easy test, debug, trace, and update project without trouble! (We hurt this issue, a single big app)
this your choice, every module been an application, or all module been under a unified App, BUT KEEP AWAY TO MERGE ALL OF THEME TO AN APP!!!
Related
For my company, I'm attempting to determine which of many mobile hybrid technologies we want to use going forward. If it matters, typically between 1 and 4 developers work on each project. We currently have about 10 mobile applications, and we plan to expand on many more.
Currently, we use Sencha/Ext for our "front end". We package with Cordova/PhoneGap to iPhone and android phones, with a MobileFirst back end to handle sessions, and auto-updates.
We'd like to replace at least the cordova and sencha part of our technology stack.
My question: Is it possible or even wise to use simple angular with react-native-renderer to create hybrid mobile applications?
Or, is it better to use a framework either separate from angular (e.g.: React Native) or in addition/built on to angular (e.g.: Ionic)?
My feeling is that using react-native-renderer with simple angular code will not provide us with many helpful features that the other platforms use. But I'd like to get insight from the stackoverflow community on this.
Thanks.
The answer to your question is yes - it is completely possible using the renderer you mentioned to utilize both features of both React Native and Angular to ship a hybrid technology. You are basically getting a React Native application in which an Angular 2 application runs in the JS thread with a custom renderer that uses the JS APIs to create a native UI.
But is it wise or a stable long term solution? The answer to that question is definitely no! This is essentially gluing two different technologies together which are both in developmental stages and will present plenty of bugs and difficulty in completing and publishing your apps unless you and your developers are very fluent in both angular and react native. Almost always it is better to stick to another framework entirely and in the future possibly integrate angular again.
Side note - run from Cordova/PhoneGap - it is not the smartest choice for any stability or consistency in development. User experience is also a downfall plus there is also serious doubt in how much longer it will be updated and maintained
I am new to Sencha ExtJS and Architect MVC, but I know MVC and some other JQuery libraries in general.
I want to ask when building a real-world system, what is the proper approach to layout an Sencha app structure in Architect 2?
For example, we have the following departments in our app, they have distinct functionalities:
Accounting, Controlling, Quality Assurance, Customer Services, Human Resources, Logistics, Purchasing, Sales, Records Management ...
Approach 1: Write them in different Sencha Architect projects. Stitch up with master layout page + main area + header/footer + side bar pages. (using MVC.NET in our case)
--- Pros:
Multiple programmers can work on different sub-projects in an agile
environment.
Each project is smaller and easier to be upgraded or replaced.
--- Cons:
We have different Sencha Architect projects for, e.g. main areas, side bar, header, footer. How do they collaborate with each other? We now only use JQuery to pass information between them, but it feels kind of hacky.
Approach 2: Write them all in one big Sencha Architect project. So, it sarts up in a single app.html page with everything in it.
--- Pros:
Now every component in the project can collaborate with each other.
A true Single-Page-App All-in-One app.html looks nice.
--- Cons:
Having hard time if multiple programmers are working on one Sencha Architect project.
It is one big complicated piece of app. Although it is seperated into simple App, Store, M, V, C categories, but we can have name crash on components in a larger project.
Loading speed may be an issue? I am just guessing here because we don't know if Sencha Architect MVC design loads relevant windows and compoents part by part or everything together.
Question is, if we take 1st approach how do we make communications between different projects? If we take 2nd approach, is Sencha Architech 2 designed to build real-world projects that way? stacking everything in one big project?
First I'll say that your thinking about this problem in all the right ways. Your pros and cons are spot on.
Second for full disclosure I'm an engineer on the Sencha Architect team.
My suggestion is to have separate projects that are more loosely coupled and perhaps connected by a portal/dashboard application. The glue app can be written in anything including Ext JS in Architect.
The reason I say this is simply that I don't like putting all my eggs in one basket and if you've built single page apps you'll know that when they're working they really hum. But when an uncaught javascript exception occurs it can force that user to have to do a full refresh to get back to a happy state. Of course if you're perfect this will never happen :p Who's perfect?
I build Architect which is in fact a very large single page application. As a team we all do our best to keep each system able to work with as little dependency on any other system(s) as possible. We use things like eventing, pub/sub, adapter and plugin patterns, etc...
These systems are very much broken into separate namespaces and directories which like all software helps developers compartmentalize. Architect doesn't fully support this idea today. However with convention you can get close. e.g. HRController, HRNewEmployeeForm, HREmployeeGrid
Having HR as a separate app however, affords you HR.EmployeeController, HR.NewEmployeeForm assuming your app name is HR. Each app being a separate project also allows for the dev team to be more agile in how it deploys!! Major win.
Other users have taken this approach and one such user graphs all his projects together using a managed iframe approach
http://www.sencha.com/forum/showthread.php?243179
Asp.Net MVC is another good approach and might afford you some features like user auth etc...
Hopefully this helps!
I'm starting to build a rather big application in ExtJS Architect and I was wondering if it is advisable to split the application into multiple projects (to be precise projects as Architect defines a project)?
At the moment I am the only engineer working on this application, however more engineers may be assigned in the future. What would be the points to consider if you would to like to split up the project in smaller pieces or build one big project?
In addition: as far as I know it is not possible to 'share' a project in Architect over more than one developer. That votes in favor for splitting the project.
Disclaimer: I have not used Architect to build a project.
My thought on the matter is that if you are building an MVC project and you want Architect to manage your controllers and views you should keep all of it together. Especially if you have cross cutting communications between modules. However if you are 100% certain that your modules are completely standalone - meaning they have nothing to do with one another and might as well be separate apps ... (maybe they should?) ... then you could build them out separately and weave them back together after you are ready to ditch the architect. Remember its a one way street not an IDE. Bringing the modules together should just mean that the app.js now lists all of your controllers for all modules instead of just one for your module.
There is a medium size database application that needs to be built featuring a web interface. The platform is asp.net 3.5 (asp.net mvc 2), sql server and ext.net 1.3.0. The tool is visual studio 2010.
I wonder, should I start with the database design and business logic and move on to the UI when I've a complete working draft/skeleton? Or should I build the database and BL step by step and bind them to the web UI as I progress?
Even more specifically, should I construct the whole BL functionality as a separate dll project and then have it referenced by the web application project? If so, what communication options do I have? web services, for example?
Last but not least, the web application requires a security mechanism (user accounts etc). Should I design and integrate it right from the start or can I add it when everything else is ready?
(I hope my question is clear enough. As far as I know, creating a dozen or more aspx pages as a means of building and testing the application functionality leads to all shorts of problems and dead ends while being extremely time consuming. What I seek is a way to separate the UI from everything else. Something like having a working prototype to show case to the customer and have the (ext.net) web UI built later as a completely separate step.)
Is there a particular reason why you are not planning on using .NET 4.0 and MVC 3? MVC 3 comes with the razor view engine, which produces much nicer and cleaner views. And if you use .NET 4.0 you can use the Entity Framework. The new Entity Framework 4.3 lets you use code first with migrations, which might be a good way to go in a project where you need to "explore" the requirements in collaboration with the customer. Using code first you build your model using POCO classes and let EF take care of the database schema. This is effective if you make lots of changes to your model, which it sound like you might want to. Check out this video for a good introduction to code first with migrations.
After 9 month developing an enterprise application using MVC + JQuery our Management and stockholders interesting to convert and switch to silverlight! they think it's more powerful than Ajax, make development speed faster than our current solution, It's Windows and Web and less headache.
Unfortunately, our stockholders dos not know anything about web and stateless state of web application and they always compare with window applications.
But nobody in our team know anything about silverlight. I am not sure that is a good decision. I think we develop as fast as possible. we develop a great framework and code generator for fast develop.
Thanks and sorry for bad English.
Dumping what you have and going for a rebuild mid development is almost always a bad idea.
For a personal project, I did exactly this. It was originally built during the betas of asp.net MVC. I got the app to a stage where it was usable (actually I still use it daily), but it was nowhere near ready for the outside world. And this was the problem; it was going to take an enormous amount of work so that other people could use it...
When Silverlight 3 was announced, I literally grabbed the backend of the app - stuck RIA services in between and had a few screens up and running that day without any prior SL knowledge. I probably could have kept going down this path but something clicked when I started to realise the power of silverlight. The goal posts for my app moved, and I began a SL specific rewrite.
Since then, I've started re-writing about 5 times over. I guess I'm still just learning how to best build an app in SL, having spent the last 12 years or so of my career working on stateless web apps, there was a big mental shift involved.
I'm a much better web developer then I am a silverlight developer, but if it was for a real project (rather then a pet side project) - it would have been shipped and out the door by now.
I'm convinced that SL is the ideal platform for most web applications (as long as it being a plugin isn't going to be any issue).
With that said, shipping is still the most important thing. SL is great, but the learning curve is steep. If you guys are anywhere near completing the app, I'd insist you forge on with mvc and maybe get someone to build a SL branch.
Re-platform an application is always costly, although if you've got your MVC right it should theoretically be easier to replace the "VIEW" part of the application with something else.
As to whether Silverlight offers you more than HTML / JavaScript is down to what you're using it for. If what you are doing is media-related or highly graphical, Silverlight might be a good choice. If your application is like most business apps (i.e. some input fields backed by some read / write to database) Silverlight doesn't really offer any tangible time saving for this kind of operation.
If the web application is public and you care about search engine indexing, semantic HTML offers the best possible option.