I'm in the middle of creating a fairly large flex application, and over time, it's started to edge toward unmaintainability.
I'm using 3 external library projects which are still small enough to remain maintainable and reusable, but the main project seems to be impossible to keep organized.
Part of the problem seems to be that I have about 30 objects inheriting from a single abstract superclass type object. All of child objects have both a logic component and a ui component which are tightly integrated to each other. The superclass object has about 60 shared methods and properties, most of which can be overridden in any of the child classes, a few of which should be overridden in all child classes.
To add to the complexity, these have to communicate between themselves, and this is usually via the container object they reside in. Additionally, the main project has to create value objects out of these so they can be sent to a FlourineFX backend for storage, and additional authentication/authorization logic.
I've created much larger projects in languages from old MS BASIC (pre VB), Ada, VB (3 to .Net 1), C++, and C# without this problem. (well, old VB tended toward this problem because of the same tight integration between UI and logic) So, is there any thing I'm missing, or is there any best practices that I can implement? (even if that means rewriting entire swaths of code)
And yes, this may be an extension to this conversation.
Do you use any framework implementations in this project? A framework would help modularise a lot of this complexity and hopefully remove a lot of the dependencies you seem to have between the application logic and views.
I'm a massive advocate of the RobotLegs framework which implements the mvcs pattern and offers dependency injection for use throughout your project. There are others out there such as pureMvc, Cairngorm, Mate. Have a look around and see which best suits your project.
It sounds to me like you really need to do a big refactor which is a risky process in such a large project. It could be well worth it if you're struggling to maintain it. If you are going to refactor definitely refactor into a framework. It's probably the area that will give you most bang for your buck (pound for the brits ;) )
James Hay's conversation starter is a good one, but for HUGE applications I would take time to test and consider memory management for some of the suggestions in that answer/conversation. RobotLegs is great and all, but I would worry about 'over-singletonization' and potential memory management issues that it would create (though I have to admit that I've never used and avoided robotLegs because of it's use of singletons).
If you were thinking IoC and dependency injection (like that which robotLegs provides), I'd suggest a look at swiz -- I really like the new 'instance-direction' swiz has taken. My only issue with it (in the current beta) is they have some cleanup issues, though these issues are easy enough to remedy (look through their source and any time you completely remove a component from the stage you'll have to play the profiling game and make sure everything is getting cleaned up --- we had to create temp functions to remove the changewatchers and destroy 'display list bean instances' until they get that stuff fixed).
The project I lead had many of the potential issues you must be worried about. Our ERP app has thousands of modules and the thing is running on client machines for hours/days at a time, constantly loading and unloading modules. Garbage collection and memory management were and is THE issues.
As for using mate, the annoying carhorn, or pureMVC, we created our own framework two years ago. It borrowed ideas from cairngorm, but overall my suggestion is to use whatever you can quickly learn, understand and teach while thinking about garbage collection. Our internal Model and View classes now use swiz (for newly developed modules) and this has made maintainability and code readability super smooth.
I hope my blabbing has helped at least a bit.
Best of luck.
It seems like you just need a clean separation of UI and domain components. Look into the component guidelines and the Presentation Patterns discussed by Martin Fowler, especially the Presentation Model.
To bring these pieces together, you might want to use an IoC container like Spring ActionScript. This is a non-intrusive framework that allows you to keep layers separated.
Don't let a framework get in your way. I've seen massive misuse of frameworks like PureMVC and Cairngorm mainly because apply them in an all-or-nothing fashion.
Related
I m working on a legacy web project, so there is no ORM(EF,Nhibernate) available here.
The problem here is I feel the structure is tedious while implementing a new function.
let's say I have biz Object Team.
Now if I want to get GetTeamDetailsByOrganisation
,following current coding style in the project,I need:
In Team's DAL, creat a method GetTeamDetailsByOrganisation
Create a method GetTeamDetailsByOrganisation in the Biz Object Team, and call the DAL method which I just created
In Team's BAL, wrap up the Biz object Team's method in another method,maybe same name, GetTeamDetailsByOrganisation
Page controller class call the BAL method.
It just feels not right. Any good practice or pattern can solve my problem here.
I know the tedium you speak of from similarily (probably worse) structured projects. Obviously there are multiple sensible answers to this problem, but it all depends upon your constraints and goals.
If the project is primarily in maintenance mode with very no new features being added I might accept that is the way things are. Although it sounds like you are adding at least some new features.
Is it possible to use a code generator? A project I worked on had a lot of tedium like this, which apparently was caused because they originally used a code generator for the code base which was lost to the sands of time. I ended up recreating the template which saved me a lot of time, sanity, and defects.
If the project is still under active development maybe it makes sense to perform some sort of large architectural change. My current project is currently in this category. We're decoupling code and adding repositories as we go. It's a slow process that takes diligence and discipline by the whole dev team. Each time a team takes on a story they tax that story with rewriting some of the legacy code in that area. To help facilitate this we gave a presentation to the rest of the team to get buy-in and understanding. We also created some documentation for our dev team that lists out the steps to take and the things to watch out for. In the past 6 months we've made a ton of progress. We don't have the duplication you speak of, but we have tight coupling issues which makes unit testing impossible without this refactor.
This is less likely to fit your scenario, but it may also be a possibility to take certain subset of features and separate those out into separate services that can be rewritten using a better platform and patterns. The old codebase can interoperate at the service layer if needed. You likely make changes in certain areas more than others, so the areas of heavy change might be top priority to move to a dedicated service. This has the benefit of allowing you to create a modern code base without having to rewrite the entire application from scratch all at once. This strategy is what Netflix has done to rewrite their their platform as they go and move it to the cloud.
Does data binding fit in a 3 layered architecture? Is dropping a grid-view on a web form and binding it to a LinkDataSource or SQLDataSource considered bad? The way I see it, that's the Presentation Layer talking to the Data Access Layer. I once heard a "professional developer" say never ever do this, so what's the alternative if you shouldn't?
The way you are doing is ok if it is a small project, but if you want your app. to have flexibility to support Windows/ Web in future then you must use Layers.
Please follow this link http://www.dotnetspider.com/resources/1566-n-Tier-Architecture-Asp.aspx
You should have a middle tier between Presentation and Data Access layers, the middle tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.
The main task of Business layer is business validation and business workflow.
When you build your business logic components into an SDK, you are effectively disconnecting it from your Web application, and any input validation that it performs. Therefore, your business logic components are the last line of defense to make sure that only valid values make it into your database.
Databinding is, of course, necessary to effectively dispay data.
Tooling is great and can boost productivity. It is equally important to understand what the tooling is generating, even at a basic level, in order to be able to effectively utilize the generated code.
The reaction you describe seems a bit extreme. If a wizard can generate some code that works for ya, then use it. If you don't understand the generated code then that is the next priority; learn about what it is doing and why. In the meantime, you have a page that people can put eyes on regardless of how it got there.
I am a bit pragmatic when it comes to tools. You do what you have to do. But, if after [insert appropriate internship length] you are still using code gen and cannot customize or fix it then you (as in the royal you, not the you you) are being lazy or stupid or both. ;-)
OT:(almost) Never say never unless you want to lessen the impact of what you are trying to communicate.
my 2 pesos.
When you're doing a small project or a prototype, go with the LINQDataSource or SQLDataSource. However, the downsides of those data sources are serious enough for you to think hard if they are appropriate. If your doing a multi-layered or multi-tear architecture, they simply don't fit. But even if your architecture isn't that strict, you should ask yourself how big this application is going to be and how likely it is going to be that you will make changes to the system in the future. How much time it is going to take you when you want to make a change to the database?
I've seen projects were the developers used those data sources, because those were the constructs that were used in those nice ASP.NET video's. However, when the projects grown from prototypes to big production applications (yes, I’ve seen it happen, the prototype seemed good enough), the lack of compile time support (your queries are defined in markup!) made it very hard to do any change to the system.
When you need to make a change to the system, that will be the time that you’ll see that the cost of the change is a magnitude bigger than the time you saved by flattering your architecture.
I have started design of a ColdFusion application that is entirely web based. Not much use of Flash forms, or AJAX.
The first version is a strict web app. Version 2 will be a Flex front end.
I want to design and build things so that the Flex layer can use existing logic. It's okay if it means I have to do extra work in version 1. I would like to harden the logic code once and not re-factor.
What are things worth considering / designing / implementing now that would greatly aid in being able to design an app in this way?
One big suggestion, depending on where you're coming from (as it's a rather big question), would be to leverage the ColdFusion component (CFC) as much as possible; the CFC architecture is excellent, versatile and powerful, it integrates quite nicely with Flex (and will do so even better in coming versions of Flex and CF), so to the extent you can design your component tier with that in mind, you'll be glad you did.
It's been a while since I wrote CF code, but on the last big project I did with it, I spent a good deal of time designing a functional tier out of CFCs to be used by the plain ol' Web app, much as it sounds like you're doing -- and then later, when it came time to bolt on an Ajax UI for a subsection of the site (it could've been Flex, but in my case, it happened to be a YUI implementation), I created a facade layer of publicly exposed CFCs whose job it was to wrap and expose a specialized subset of the functionality provided by the first tier. Doing so allowed me to leverage and extend existing code in a way unique to the services that needed it, without having to expose the underlying (first tier) CFCs directly.
I'm sure other folks will have many more (and probably more detailed) suggestions, but that's the one big one I have for you first off -- learn, know and use the CF component. Good luck!
I agree with Christian that the best thing you can do is put everything as far as database logic or any other logic for the application in CFC's, and more specifically, I would suggest using webservices. The main reason for this is that it will allow you to eventually have your cf code, which is all of your database persistence and logic on a different server than where you serve the flex applications from, and would allow code reuse for other applications as well. The nice thing too about writing your cfc's as webservices is that you can use them either as webservices or directly as components in Flex using AMF (remote object). Now of course how much those benefits really apply to you depends on your situation, but its a good plan to follow.
But the main suggestion is to think of your application as having a presentation layer and a logic and persistence layer. If you are making a decision, it goes in the logic layer. If you are showing a screen or doing anything with presentation, it goes in that layer. Keeping those things separate will allow you to more easily switch out your presentation layer to flex later on.
Also, it can be useful to trap any errors thrown and return messages as results (with any results, like in a structure) from all methods. Flex has a nasty habit of telling you something went wrong, but not passing along the error information. This will help you to debug and handle any errors that get thrown much easier.
Check out Matt Woodward's presentation on the topic, it's very informative:
And a few general things to add to the answers everyone else provided:
Encapsulate your data interaction in CFCs (typically in Services which delegate to Gateways and DAOs)
In most cases, you'll want to create "bean" CFC's to represent your business objects (users, widgets, etc), these are what will transfer to Flex as ActionScript classes. You'll need to add cfproperty tags to them to make them serializable to ActionScript (case- and order- sensitive!), so pay attention to that when you create them to prevent having to deal with it later, and use one of the code generation tools like the Adobe CF Extensions for Eclipse or Illudium PU36 to do it for you.
Create a remote facade CFC (or set of CFCs depending on how big the app is) that delegates methods to your Services - this is where you set the access for your methods to "remote" - generally the only place you want to do this (it will feel like you're doing a lot of delegating but it pays off to have all your remote services centralized)
As you develop with HTML, treat your remote facade CFCs as your API and make your HTML views as "dumb" as possible. Think of it this way: any logic you write in your CF view will have to be replicated in your Flex view. If you build the project only using your remote API, you'll have a pretty good feel for how Flex will interact with the application.
Check out ColdSpring, it offers a lot of great features for managing all the objects you're going to create!
I don't claim to be an architecture expert and I know I've thrown around a lot of jargon here to keep it short, but some Googling around CF blogs should turn up a lot of info about the design patterns I've mentioned. Good luck!
I am just starting a new ASP.NET project and using the MVP pattern. I did consider the MS MVC but it is not released yet and would be a big learning curve for some people on the team, so I opted for MVP now and possibly future projects MVC.
Anyway, it seems I will have a single Controller/Presenter class for every webform I have it the project. This is a lot of extra classes, essentially doubling the number of files in the web project. Is this how other people structure MVP or what are the alternatives?
This seems to be a common misconception -> "More files/classes == more complex"
The reason we chose to follow a UI separation pattern is to help separate concerns, make code easier and cheaper to change and maintain and (big, important and) we can unit test the complex parts and still keep the UI layer slim.
I'm going with the beta ASP MVC. The reason being, that while it is still only a beta (PDC very soon, that may have an impact on release and we've had 5 preview releases) it has a better framework to support this style than I could write in a reasonable time frame.
You could of course go with another framework, like castle monorail.
I think a lot of it depends but in most cases that is really the way it ends up going.
I personally use a n-tier architecture with data, business, presentation code. (Who knows what actual format I follow). I do get a lot more files than if I did everything in the aspx, but the code is much easier to manage.
To your question - I have seen many different takes on MVP and seen nothing that reduces the number of files, and I can't think of a way to reduce the number of files.
In my experience, I have reused view interfaces and even code behinds where the view structure is identical, but presenting different data. And you could also think of reusing the controllers where applicable.
I think it is worthwhile to note that having more files will be a natural consequence of moving to a more agile and test-drive development and developers will find it more and more natural as they go. (Just like some of us find it very natural having lots of methods inside a single file...)
There are so many reasons why using an MVC framework in Flex rocks, but picking the right one seems tricky. I am interested in what you all think from your experiences of implementing either of these (or another).
Sam
The question has already been asked, however since you ask specifically for the benefits of Cairngorm and PureMVC specifically, these are my thoughts:
Both PureMVC and Cairngorm make it hard to write testable code. This is mostly down to their use of global variables that tie your application code together tightly, making it hard to isolate any part for testing. This is more true of Cairngorm than PureMVC, but both are pretty bad.
PureMVC is more invasive than Cairngorm (meaning that your code is heavily dependent on the framework, e.g. you have to subclass/implement the framework classes/interfaces), but that doesn't mean that Cairngorm isn't.
Cairngorm is full of anti-patterns like heavy use of global variables, PureMVC hides the worst parts of itself.
PureMVC is anti-Flex, Cairngorm just doesn't use many of the good parts of Flex. By this I mean that PureMVC reinvents many things that Flex already have, because it wants to be platform agnostic, and because of its architecture, specifically the mediators, it makes it harder to use bindings to their full power. Cairngorm just skips over things like event bubbling, and instead opts for solutions involving global variable.
In short, Cairngorm is the VisualBasic of Flex, it works but will teach you a lot of bad habits. PureMVC isn't so bad, it just isn't a very good fit for writing Flex applications.
What I think you should look at is Mate, which uses Flex to it's full potential, and it isn't built around global variables. Instead it helps you write loosely coupled, testable, reusable and maintainable code without the heavy and needless dependencies on the framework that you see in other application frameworks.
If you for some reason don't like Mate, try Swiz, which is a great improvement over Cairngorm, but still has some weird preference for using global variables for central event dispatching (which is completely bizarre considering that one of the points of the framework is to avoid the evil global variables of Cairngorm).