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).
Related
I am trying to make a website in ASP.NET MVC, but I am not really sure how I should organize things. N-Tier applications seem to work nice, but since I am a beginner programmer it is pretty hard to understand. I just want to create a small web application where people can login and create pages. In these pages they can add others things. The database won’t be bigger than 10 tables I think. Even though it is a small application, I would like to use some best practices that N-Tier applications use.
Is this a good approach? Or is it very wrong? :
Project.Models
Models that represent the entities in my database.
Project.DAL
Interfaces and implementations for my repositories and unit of work. Also my NHibernate mappings.
Project.BLL
Interfaces and implementations for my services.
Project.UI.Web.MVC
My controllers, viewmodels and views. The controllers get data from services and pass data (viewmodels) to views so I think it’s part of the UI.
There are no hard and fast rules about how to organise your project.
That looks pretty logical to me and seems to follow a lot of hte examples that i have seen across the internet.
All that matters is that its logical to you and your team in my opinion.
Take a look at this link as well, might be a lot of useful information for you there:
Best practices for MVC architecture
That sounds like a neat layering.
Define clearly on what goes in DAL, BLL and Web.MVC. Because people can have difference in opinion in what goes into business logic and ui logic, I suggest to have a weekly review of what has went into each layers - to start with.
One suggestion is to call Project.UI.Web instead of Project.UI.Web.MVC.
I would like to know the best practice for a designing a simple CRUD application with some screens updating various tables (like admin pages to maintain static data for an application). the simplest way would be to drag a data grid/gridview, bind it to a dataset and use a data adapter for CRUD operations. but if this application needs to be scalable, lets say to add any extra UI/business logic in future, then is there any design pattern that can help with this? should I be using an object data source control and bind it to business objects instead? or are there any better ways of doing it? should I build a complete layered application or will that be overengineering for this requirement? any examples for UI design would also be helpful. thanks.
If you are looking for a really quick and easy approach, you can look at using Dynamic Data
http://www.asp.net/dynamicdata
on top of a Linq2SQL or EF4 backend - hardly any code needed at all.
+1 Oded. No offence RKP but you might be confusing "simple" with with "effective" or "value-for-money". I also think you might want to be more clear about exactly what it is you're after: example UI designs is quite a different issue from the logical architecture. Anyway - good on you for asking.
If this is a "tactical" solution: not expected to have a long life-span, or is a quick-and-dirty dev tool then how you build it might not be such a big issue. (also beware that short-term tactical apps can end-ed being long-term strategic ones - were working on an app now that the business see as a "temporrary" tool: they see it only being used for the next 5-10 years (!)).
If it's a tool the "business users" will use, then it's quite likely they'll expect changes overtime: depending on what the app is for a simple pass-through CRUD app might only cut the mustard for a short while.
So I guess this is where your admirable desire to look at best practice comes in.
Are you familiar with OO design? A lot of the principles behind good OO design also apply at the architectural level (SOLID, Common Reuse, Common Closure, Loose Coupling, Stable Dependancies and Stable Abstraction Principles).
lets say to add any extra UI/business
logic in future
So - this is where you need to consider up-front how you will seperate concerns and allow for growth: architecture doesn't mean you have to do a big upfront design, it just means you need to have an idea of how you'll grow the application as requirements grow..
To finish:
Have a good look at the different system quality attributes and work out which ones are particularly relevant to the system. prioritise them.
I get a lot of mileage out of Dependency Inversion (The D in SOLID) - abstract out things like data access early on.
For me the other really key "best practice" is to pay attention to SRP (the S in SOLID),
http://www.asp.net/mvc is my bet. It's easy to start with and get going... You won't be dissapointed. :) StackOverflow itself is built on top of it.
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.
We are currently designing a business application that has two primary requirements for it's UI:
1) run on the Desktop (WPF) for enterprise users to provide a rich user interface, interoperate with other applications, access the filesystem, work offline, work with special local hardware, etc.
2) run on ASP.NET/Ajax to provide several components of this application to customers (internet). Unfortunately Silverlight is not (yet) an option.
Even though we don't have to make the full application available on the web, some of these components are fairly complex and we would like to share as much UI code as possible with the WPF implementation.
What options do we have to reach this goal? Is there a pattern that works well with both technologies?
Update:
Thanks for the answers even though they don't include the one I was looking for! :)
I don't think UI generators are a good option. Like Eduardo pointed out you will probably end up with problems in both worlds. I will check out Sculpture though.
I've been thinking along these lines for a while now, and I've yet to come up with a great answer. That being said, here are some of my thoughts:
If you used some variation of the various MVP/MVC/MVVM UI methodologies and you were very disciplined in this approach (i.e. not mixing presentation stuff with behavior stuff), you'd probably be farther down the road.
You might consider investigating the various DSL toolkits that have cropped up, the idea being to create a simple "language" to describe your UI at a high level and generate a representation of that UI in WPF/ASPX.
Also, I ran across this recently. I have no idea how good it is. I'm planning to take a closer look when I get the chance.
Good luck!
The unfortunate truth is that Asp.net/ajax (the web in general for that matter) and WPF (and heck, let's throw WinForms in there for good measure) have very different User Interface models and what works well for one is not necessarily going to work well for another. That's not to say that you can't share logic between applications written for either technology, but, I'll make a stretch here, your UI logic is not going to be in that category.
I've been using a variation of MVVM for WPF and ASP.Net MVC most recently and I'd say they are very good fits for the technology at hand. However, while they are very similar, they have their differences and I'm not sure you could write an abstraction layer (in any decent amount of time) that could take advantage of the great features in both technologies.
Ultimately, I'd say that your best bet is to follow some SOA patterns and extract as much of your business and data access logic into common libraries as possible. Then, write separate user interfaces in WPF and Asp.net to take advantage of those common libraries. This is the approach that my company is taking at the moment, and it's working like a charm.
It may seem daunting to write your UI logic twice (once for asp.net and once for wpf), but I think it's worth it so that your code can fit the patterns and practices that best fit those technologies.
As an aside, even though Silverlight is not an option, have you considered XBAP?
If a former job we did something similar. As Daniel Pratt says, we describe our interfaces in XML and then a render will create the form, report or whatever we decided to create.
We have to provide a Javascript function to do some UI validations in the HTML render, and a call to a java function in the Swing render.
Beware that you may end with imperfect apps in both worlds.
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...)