Right now, I’m working on a legacy web application that is made up of multiple screens, each one performing a separate function. I’m in the process of converting several of the screens to EXTJS 4 using the MVC approach. In order to isolate the impact of my changes and because we don’t have time to convert the entire app at once, I’ve converted two of the screens into two separate EXTJS 4 apps. Each screen now has its own folder in which I’ve set up an app using the appropriate file structure and app.js file.
My question is this: as I continue developing, I may want to use models from one app (screen) in another app. How do you share models, views and controllers between applications? What’s the best approach?
FYI, I’m using autoloading to pull everything in.
Thanks
I would not use autoload in production, because it generates to many HTTP requests to get all files, which slows down the page load speed. This is well documented at Google's Page Speed and Yahoo's Best Practices for Speeding Up Your Web Site.
The best practice is to preprocess the resources upon deployment of the application and generate a single javascript file with everything in it that is sent in a single (GZIP) compressed response. There are several tools for this job, but it depends heavily on your toolchain. You can for example have a look a the SO question Best JavaScript compressor to get recommendations for various compressors (I use Jammit).
When you have a flexible configurable JavaScript compressor in your toolchain, you can set up a shared folder where you have your common files, like model, stores and some libs. These are now included in the builds for the different projects.
In case you have a good reason to serve single javascript files, you can either use a good version controll system like git and make use of submodules. Which this approach you'll have a separate repository for common files. This gives you the downside of slower page speed and a little overhead with updating the submodules.
As last solution, you can use a symbolic link on the file system to link the common folder to the different other projects.
Here's what Saki said to me on the Sencha Forums:
The multiple applications on one page, or sub-applications of Ext MVC
are not supported yet, however, developers are working on this
functionality, AFAIK. Such implementation would most likely solve also
the problem of re-using models, views and controllers among (sub)
applications, I hope.
More specifically regarding linking multiple applications:
I would just soft-link files of MVC components is this case. There's
no logical or functional connection among them now, only I wanna reuse
already written file, right?
Related
I have created three different solutions for three different clients, but those solutions are for an app that have the same features, classes, methods, resolution, except for the images, XML resource files, and a web service reference, that are specific for each one.
I would like to have just one solution for all those apps, that I could open in VS2010 IDE for edition, without errors. So, when I need to build or publish an specific app, I just set the client which one I need to, and go ahead to building or publishing.
It is important to consider that XML file names will be the same, as classes and images names too. The difference will be the content, but the name will always be the same.
My intention is to reduce my effort to maintain many solutions, having just one solution to work with.
In my company, we will have more than those three clients soon, so I am worried about how to maintain that. The best way will be have just one solution and when I need to generate a new app for a new client, I have just to change/include a few things (like some resources and images) and compile to a new client folder.
Is it possible? If so how?
One option would be to have a master solution which had the following
A "Template" project that contained your actual application and all of the shared code
Projects for all of your clients
In the projects for your clients, you could have links to the files in your files that come from your shared project. Then, in each of those projects, you could add the files that are only specific to them.
With this kind of structure, whenever you made a change to your Template project, all of the client projects would be updated as well because they just have pointers back to the Template project.
A good reference for this kind of setup would be the Json.Net Code Base. There he has a solution and project for all of the different configurations, but they all share the same files.
In terms of ensuring that the xml files are named properly, you might just want to put some checks into your main application to ensure that it has all of the files needed or potentially add a check into your build process.
There are many ways you could look to tackle this.
My favorite would be to run some sort of pre-build step - probably outside of Visual Studio - which simply replaces the files with the correct ones before you do a build. This would be easy to automate and easy to scale.
If you are going to be building for many more than three customers, then I think you should look to switch from Visual Studio building to some other automated build system - e.g. MSBuild from the command line or from something like TeamCity or CruiseControl. You'll find it much easier to scale if your build is automated (and robust)
If you don't like the file idea, then there are plenty of other things you could try:
You could try doing a similar step to above, but could do it inside VS using a pre-Build step.
You could use Conditional nodes within the .csproj file to switch files via a project configuration
You could look to shift the client-specific resources into another assembly - and then use GetResourceStream (or similar) at runtime to extract the resources.
But none of these feel as nice to me!
I have many bundles (let's say hundreds) and it is quite difficult to specify relation between bundles+features-distrubutions in UI. Image, at first I define all relations between bundles, features and distribution. Than I want to update some bundles... it is almost impossible to find them in current implementation of UI. They are not groupped and one list of all bundles without any search bar is really hard to work with.
Is there any support for a file based solution. For example Apache ACE would watch a certain folder containing distribnution's bundles. When ever I make a change there, it would be propagate it to all targets.
There is currently no file based solution that matches what you describe, however, I think there are still a couple of solutions that might help you:
There are two types of associations between artifacts and features in ACE: static and dynamic ones. The latter can be of help to you, as they always automatically bind to the highest version of a bundle. So, once you've made all your associations, you can simply upload a set of newer bundles and the associations will adapt.
There is also a REST API you can use to programmatically talk to ACE. You can use that to further automate your process.
That said, you have a valid point that it is difficult to keep an overview when there are a lot of artifacts in the first column. I would advise you to watch, or even contribute to the following issues that were all created to improve this situation:
https://issues.apache.org/jira/browse/ACE-319
https://issues.apache.org/jira/browse/ACE-320
https://issues.apache.org/jira/browse/ACE-321
I seem having difficulty in understanding the reason behind the need of having many projects inside one solution (in my case visual studio 2010 with c#).
The only use that comes to mind is if I am creating a new classes I can test them in a console application first, then add another project to the solution to use these classes with the project that I want.
kindly guide me to the correct way, thanks.
A typical project might have a UI, a data layer, a services layer, and a domain layer, as well as some tests. A typical arrangement would be for each of these to exist as their own project file. The solution would contain all of these projects so that you can make modifications and debug different parts of the app at once.
If you're just starting out, you probably cram all of this stuff into one project. That's fine for learning, but is an absolute mess for maintainability and reusability.
There are 3 main reasons that immediately come to mind for splitting your solution into multiple projects: Reuse, Encapsulation, and Project-specific settings.
Reuse
You may have a Utilities project that is shared between more than one solution. You may also have data access and business rules that are defined in class libraries, but are shared between multiple UI projects, such as having a business application that has a web interface, a desktop interface, and web services. They all need to share the same logic and data model, so you wouldn't want to replicate it in each solution separately.
Encapsulation
Another reason is to achieve encapsulation, one of the main principles of OOP. Your classes may have internal methods and properties (or the classes themselves may even be defined as internal), which makes them only visible to other classes in the same project. If it's there to achieve a specific purpose but not something that should be accessible to all, by splitting your classes across separate projects you can make those properties, methods, and classes visible to your classes, but hidden outside the scope of your project.
Project-specific settings
There are certain project types that behave completely differently from one another. A Web Project is different from a Windows Forms app, which is completely different than a WPF app. This kind of goes along with #1 and trying to achieve code reuse; since you can't have a single project that is a website AND a Windows Forms app AND a WPF app, you create each UI as its own project and put as much logic as possible into a separate project that can be shared between all of the UI projects.
A couple possible reasons off the top of my head:
a project may be useful in more than one solution
simple organization utility - just like you might have classes in separate files even though a single source file can hold multiple classes just fine.
There doesn't seem to be any tried and true set of best practices to guide you on how to setup your solutions, projects and the assemblies they output. Microsoft seemed to have tried back in the VS.net days, but they have since retired this content. For every method I read about I read another that claims the opposite is better, or a post that only concerns itself with "if only Microsoft would..." but really provide no solutions.
It appears there are many ways to do this that all seem to work for various groups in their situations, therefore I thought I would ask what conventions YOU use and why they work for YOU in your situation.
I hope that this will provide several good conventions for different situations, small development groups and projects to large diversely located development groups and projects.
What conventions do you use to...
name your solutions, and why?
name your projects, and why?
name your assemblies, and why?
know when to create a new project or add to an existing project, and why?
know when to split up a solution into smaller solutions, and why?
know when to break up a project into multiple projects, and why?
Just to be clear, the WHY is just as import as the HOW in these answers. There are many answers posted on the how here and other places, very few say why they use one convention over another.
That's a very broad question, but a good one. I will start with a simple structure that I use for ASP.Net web projects (MVC will look completely different).
Solution naming isn't a big deal to me. I tend to create solutions for a specific purpose, and add existing projects to the solutions. If your solution is over 15 projects (just a rough number) consider adding some of those projects as references. Most people don't need to work on more than 15 projects at a time.
Project Naming is a big deal to me.
// class library that supports the site itself and abstracts
// more complicated UI logic into a separate place
Company.ProductName.Web;
// website
Company.ProductName.Web.UI;
// main business object library for product
//
// of course, you can have as many of these as needed.
Company.ProductName;
I try to use enough folders in my projects so that all files in a folder can easily be viewed without scrolling the solution explorer.
My typical web project looks something like this. Note the different in casing to represent namespaced/compilable resources versus those that are not.
client (css, javascript)
config (private, custom config files, if any)
Content (Master Pages, ASPXs and ASCXs, broken into logical folders)
Handlers (ASHXs and such)
images
MSBuild (build scripts)
WebServices (these should ONLY be small services that are directly related to the site in question. Otherwise, break them into a separate project).
I've started using partial classes more and more to create comprehensive classes that can do many things without having the code be cluttered. For example, I recently created a web service whose single purpose is to return JSON to the client, but the logic is spread across almost a dozen partial classes to organize it better.
Hope that gets you started.
In our case we keep our project names quite identical to namespaces that we chose for particular assembly. That way it becomes easy to map location of a class file in physical folder. For example - CompanyName.BusinessLine.BusinessService or CompanyName.Framework.Security. So if a developer is looking at CompanyName.Framework.Security.Cryptography.cs, he can immediately figure out the project and open that project.
As Tim says, this is very broad. A few things to note:
A solution is usually just a collection of projects. Many solutions can include the same projects, for example. As such, it doesn't matter too much: if you don't like a solution name, you can throw it away with no refactoring at all.
Like Pradeep, I tend to name projects with the top level namespace they contain. "Deeper" namespaces end up in subdirectories, so classes within the Foo.Bar.Baz namespace might be in the Baz directory of project Foo.Bar.
I tend to split into projects across:
Elements of reusability (e.g. one assembly for a UI, one for a reusable set of model classes, one for a reusable general purpose utility classes)
Elements of deployment (e.g. one for production, one for testing, in pairs)
Elements of reference (e.g. if you have a common assembly Skeety.Common with some interfaces used by other classes, there might be a Skeety.Common.Testing assembly containing types which help you to test classes using Skeety.Common). This leads to these rules:
Production assemblies can only refer to other production assemblies
Testing assemblies can only refer to production assemblies and other production assemblies
Test assemblies (the ones containing the tests themselves) can only refer to production and testing assemblies, not to other test assemblies
No circular references are allowed, obviously
In many cases it actually doesn't matter too much how you split things up - but it does help to make the design cleaner as you work out the dependency layers (so a business logic assembly shouldn't have a reference to a UI assembly, but vice versa is fine).
Having too many project can definitely slow you down, both in terms of build times and just working out where everything should be. Having too few projects makes the design less clear. Over time you're likely to get more of a gut feeling for how things should be laid out - but I'm blowed if I'd claim to always know the best course of action :)
I'm tired of looking after a frame work for mvc implementation.
i want to build a good MVC based structure of my own that will serve me in my projects.
so here is my thinking I'd like to know what do you think.
first of all. here is the folder structure:
The folder structure
the Admin and the Site folders:
I assume that the controllers/views in the admin/site and are totally different one from each other,
so it is necessary that they will be in independent in each folder.
if the autoload in the admin or site folder will not find a view/controller in its folder he will look for it in the MVC folder
the model, which is the db layer can be inside the MVC folder because it is shared to the entire project.
a function like get_article_by_id can be used in the site and in the admin as well.
the MVC folder:
will hold the entire project models. and shared controllers/views.
the classes folder:
will be use as a framework folder, it will hold classes such as mailer,db that will implement php functions
How does that sound to you?
Part of the benefit of using a popular framework is that other people know it and can help you with it. If you write your own, only you know about it. There is an MVC framework in almost every language and lots of thought has gone into each one, which means you get the benefit of a lot of experience by selecting an existing one, rather than writing your own.
As long as you feel convenient with this structure - use it.
If you need to ask advice about whether your reinvention of the wheel is any good then it's probably not better then the wheels already in existence.
A wheel inventor that knows he has a better wheel wont need to ask advice.