I am trying to create a large flex project. This Project consists of a CORE application, and other sub-applications.
The CORE application should contain information that will be shared by all other projects (e.g., link to database, data manager which loads data from the database, application information like height width colors fonts... etc.).
The sub-applications each has a certain task. Each sub-application is a large project by itself so I don't think its a good idea to put all code inside one HUGE project.
The CORE project should run the main application, and through a navigation menu, I should be able to click and run other sub-applications.
Is there a way to created the CORE application to reference those sub-applications so that I can run them inside of the CORE. At the same time, those sub-applications should reference the CORE applications to get the NetConnection to the database and other important information that they might share?
What is the best way to structure this project?
Thanks,
There's two factors to consider.
Where does the code live
Where does the compiled output of that code live.
It likely is a good idea to have all of the source code live in a single code tree. It's way easier to maintain like that. You could put each sub-application in a separate AS3 package.
It's also likely a good idea to separate the compiled output of that code. Make your core application the main flex application, and then make each sub-application a Flex module. The core app can load modules and manipulate them like any other AS3 based class. A great thing about this, is during debug time you can choose to only build the limited set of modules that you care about at the time.
I would highly suggest building your releases through some kind of automated ANT build script and not through Flex Builder.
We have one project that exceeds 150k lines of code that is managed exactly like this. That's not huge in terms of software-engineering, but it's pretty big in the Flex world.
Your best bet would be to put the CORE stuff you're suggesting into a library project. Keep the front end of the application in a Flex Application Project, but all of the data and methods that need to be shared would be easily available to the main application and all of the other modules or applications.
Then in the project settings for your main app and the other applications, you can link to the library project.
If you're planning on using a framework you can also look into the PureMVC Multicore library. It's a bit more complicated than the solution I provided above, but is built specifically to allow the sharing of data and notifications between separate applications.
It sounds like you want to use Flex modules to keep your sub-applications self-contained but still able to interact with the core application.
http://livedocs.adobe.com/flex/3/html/help.html?content=modular_2.html
This will allow you to keep your core application SWF fairly small and load the subapplications on demand.
Typically modules are stored in the same project as the main application but each app / module is compiled into a separate SWF either by Flex Builder or an automated build tool such as Ant or Maven.
Related
I am currently starting the development of a new website using ASP.Net Webforms. To give this project a proper start I am investigating a visual studio solution setup for the application, where I want my application to consist of easily recognizable components that are equal in size (lines of code).
Since the project is hasn’t actually started yet I have structured the solution in a standard three tier setup (data, business logic and presentation). This setup is fine at the start of the project but as the project grows the three tiers will soon start to become big and navigating and finding code will become harder which will hurt maintainability and overall feel of quality.
So during the project I want to convert to a new setup where I form functional components that each has their own three tier setup. For example: the website has a shopping cart and options to create and manage a user account. There should also be component for stull used across multiple components, which I will call common for this example. That would lead to the following setup:
The common files:
Project.Common.Data
Project.Common.Business
Project.Common.Presentations
The shopping cart:
Project.Shoppingcart.Data
Project.Shoppingcart.Business
Project.Shoppingcart.Presentations
The account management:
Project.Account.Data
Project.Account.Business
Project.Account.Presentations
The website:
Project.Website.Data
Project.Website.Business
Project.Website.Presentations
The sample above has three components that each contains three projects. Each component has one web application project that contains web files (pages, controls, front-end code). All my previous .Net project all had a simple web application project, so this setup is a new experience for me.
I still want the solution to feel as one application, being able to debug the website and the components with ease. To achieve this I assume the “Project.Web.Presentation” web application project should be the main web application project. I am currently investigating if it is possible to setup a solution this way, I have tried several approaches but none have worked well so far:
Running all the web application project separately, this worked fine but I have to run all the application separately and I cannot run them under the same port which is terrible when debugging.
Adding files from other presentation projects as links to the “Project.Web.Presentation” project and set that project as startup project. This doesn’t work as the files aren’t present at debug time, seems to work fine when building a deployment package. I do not want to copy the files since I have to somehow prevent those duplicate files from ending up in version control.
So far I haven’t found a good way to work with setup I have in mind. I am open to suggestions, thanks in advance for the tips!
I'm working on something similar and decided to use NuGet to push out all the common parts:
Multi-Project Nuget Issues
Updating Files in Existing Nuget Package
Visual Studio Multi-Project Solution Options
The only other way to do this involves nested master pages and post build scripts - messy.
I created an empty Visual Studio solution and added two projects: Backend(Class Library type) that will have the.edmx file for accessing information; and Frontend(ASP.Net type) that will have the database in the app_data folder.
Is this a good architectural design or is there a more proven way to organize this type of application?
Splitting the data access code into a library project is a good idea. I'm currently working on an ASP.NET project which is almost the same - I have a library class that I use to access the data, and in the other project I have my aspx pages. The only difference is that my data is in SQL Server (using entity framework to access that data via a .DBML file).
For the type of site you're building (data in the App_Data folder) it sounds like it will be a simple site which does not need to do anything too intense i.e. scaling.
Most often it depends on the size of your project, but generally I tend to separate the front-end stuff from the backend s.t. it gets reusable. So to that direction your organization is already fine.
If you want to go a step further, I'd take a look at layered application architectures. This post here may give you some insight into that and you may find some reusable elements.
Personally I don't really like the DB to reside in the "app_data" folder of the UI project (i.e. the ASP.net Web Application project). But for small apps it's fine :)
I'm working on a pretty big application for Flex/Air. We are using GraniteDS and Tide to interact with the model from our Java EE server.
I've been reading about modularization and Modules in Flex. The application has already been built, and I'm figuring a way out to re-design some classes and parts. From what I've read so far, I understand a Module is a different swf which can be dynamically load. Most of the tutorials/documentation are oriented to Flash "programmers" who are using Flex or Air instead of real developers, so that makes online resources harder to get.
What I can't understand - yet - is how to encapsulate ActionScript classes or MXML views under this module.
I've separated some of the code into libraries. For example, the generated code from Granite is in a "server" library. But I would like to separate parts of the logic with its Moderators, Controllers and Views. Are modules the way to go? Is there a "modules for dummies" or "head first Flex Modules for programmers" like tutorial in order to get a better perspective in order to build my architecture? When to choose libraries and when to choose modules?
I'm using Flex 3.5, and a migration to Flex 4 is way far into the future, so no Flex 4 answers please, thanks!
Modules are the answer for encapsulating UI into different sections that do not depend on each other. Think of them like applications inside of applications.
If you want to encapsulate "code", meaning non-ui actionscript, then you really just want classes and packages of classes. You could also package that code into a swc, which is just a compiled version of that code that you can include in multiple projects (I think this is what you meant by libraries).
You wouldn't want to create a module just to contain non-ui code. You wouldn't want to use modules for separating out the model/view/controller in your application.
If you have part of your application, that for the most part runs completely on its own, with no real dependencies on the rest of the application except for maybe a little bit of information passed in, then it makes sense for modules.
Where we use modules mostly is for an application that has different sections to it where you are only working in one section at a time. There is no need for the other sections to be taking up resources, so we have the different sections in modules and load/unload them as necessary.
Does that help?
Edit in reply to the comment below:
By libraries I meant Flex Library
Projects, where you encapsulate
classses and use the swc. Can you have
these libraries inside a Flex Project?
(I use a separate Library Project for
each new library).
Yes, you can use these swc's (Libraries of code) inside of your flex projects. Just drop the swc in the lib directory in your flex/flash builder project and the code is automatically added to your classpath. Just make sure that everything that the code inside a single swc needs is inside that swc. Don't make a swc rely on another swc to function.
I'm doing some work with several shared .NET assemblies and a generic web application that I would like to handle better in our CC.NET/NAnt build environment.
Currently, we have several .NET assemblies (shared common code that we use in client projects) that exist in different .NET solutions within different repositories in our SCM (Vault incidentally). They are all configured under CC.NET separately so we have a decent amount of control over their build and deployment at present.
We have developed a CMS system that uses some of the .NET assemblies and includes a common administration website project and a template website example project. Out of this one solution we have the following elements that need to managed separately:
Admin interface is not tied to .NET so it is template based and we are developing a PHP backend for it currently.
CMS shared assembly build on top of our other common company wide assemblies.
Control over functionality within each major CMS build/release.
I'd like the build output of this solution to be a Visual Studio template, which we can use to develop other client sites and better manage version changes within the CMS itself, as we add features to the codebase.
I have a rough approach for all this and think it is achievable, however, I wanted to open this topic up for discussion and see what everyone else is doing when it comes to managing the build and deployment of multiple solutions.
Main considerations for us are:
Do we make use of the integration queue functionality in CC.NET to ensure a build order and pull together the assemblies we need for the CMS at build time?
Debugging within a CMS client site i.e. stepping into the shared assemblies' code when the client solution is a version of the base CMS system and therefore separate.
Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?
Any other issues people might have experienced that could change our way of thinking?
Hopefully this question isn't too vague and some of you will have dealt with these issues. Look forward to hearing everyones experiences.
Many thanks!
Tim
I unfortunately cannot answer all of your points, but let me start with this one:
Do we make use of the integration queue functionality in CC.NET to
ensure a build order and pull together
the assemblies we need for the CMS at
build time?
The short answer is -yes, you should. The queue attribute ensures a build order within the running instance of CC.NET and is gives you serialization of the builds that depend on each other. For specifying which projects depend on each other, you should use project triggers. Do not rely on the queuePriority for this task.
You shold most likely pull the pieces you need to do the build at build time. Unless you have some time constraints on your individual builds.
Re:
Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?
I'm fundamentally against distributing binaries in the trunk unless it's some libraries that does not need to be updated/changed on a frequent basis. If you build the shared assemblies yourself, you should consider pulling them from the artifacts on the build server(s).
I'm new to Air. I've got an existing Flex 2 application which I'm considering bringing into Flexbuilder 3. My question is can I use the same base application (and source code) to make the Air version, or would I have to maintain to separate code trees: one for the Air version and one for the Flex/SWF version?
The best approach I've found to creating both Flex and AIR applications from the same source, is to use a core library project for almost all code, with separate small projects for the Flex and AIR applications.
There are two key concepts that make this very powerful and maintainable, allowing for not just two applications, but for many "editions" if you're so inclined.
Modules:- If the core application is
actually a module (or a module that
loads other modules) you'll be able
to easily create stub Flex and AIR
applications that are basically
there to set project properties,
reference classes for cross-module
communication, and then simply load
the core application module with a
ModuleLoader.
Factory Objects:- When there are
things you want to do on the AIR
desktop application that you can't
do in the Flex application, or any
case where you want something to
work differently across
applications, a factory object that
creates an instance of a project
specific class is a great way to do
it. for example, you can call your
"save" function, which for AIR saves
to the file system, but for Flex calls
a web service.
Have a look at Todd Prekaski's
excellent Flex DevNet article on
Building Flex and Adobe AIR
applications from the same code base
on how to do this.
Once you've created a Flex Library project where you're going to create your main module, create your Flex and AIR application projects. In the properties of the two application projects add the library project src directory to the Flex Build Path. While in the project settings you'll also need to add the modules to the Flex Modules section, setting the option to optimise for the project.
You can't mix both AIR and Flex in the same Flex Builder project, but you can share code. Here's how...
Create a Flex based project as you
normally would.
Create a second AIR based project.
In the second application, go to
project->properties.
Select the "Flex build path" option.
Under "Source Path" add the folder
that contains the source from your
first Flex based project.
Now both projects share the code from the flex project.
You need to be careful not to use AIR only API's in code you intend to share between both apps.
You can use the same.
One way is to put the bulk of the application in a Group-based component in a library.
Both Flex and AIR applications can embed that component in their Window.
If you need to have custom code, have your Group component accept an Interface object that has all the methods that are specific to a platform (loadFile, saveFile, etc.). Each application injects an object that implements these methods appropriately.
I've worked on a product that injected a whole local-data access layer (to the SQLite database) and the core application had no idea if it was running in a browser or on the desktop (connected or disconnected).
Cheers
Create 3 project: Air, Web, and common. from air and web, include common.
http://simplifiedchaos.com/how-to-compile-both-flex-and-air-application