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.
Related
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 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 have read many articles on the MVP pattern. Some folks say it is too complex and some say it's outdated. However to me it would seem like the perfect way to provide unit testing access to the UI - which is what I'm aiming to achieve.
Have you used MVP and if so what do you think?
Model View Presenter, Model View Controller, traditional three tier (UI/Business Logic/Data Storage) or virtually any other architecture that isolates the various concerns of your code help you write tests.
Often the architecture is somewhat dictated by your tool: the Asp.Net MVP tags seem to indicate that you have already made your choice there. The trickiest part to test in any configuration is the UI, because even if you create a mock UI that performs all the functions the user can... at some point you will have to render it in a browser and assure yourself that the theory is sound.
Note that this does not discount the benefits of a mock presenter UI with unit tests that exercise all the options the user will have: doing so puts you light years ahead of someone doing straight UI testing alone. On the other hand, I have yet to find a program where the UI always rendered as we expected in every browser. Finding these cases still requires human intervention (or at best something like Selenium or Test Complete once you have the initial run-throughs).
Regarding the "obsolete" aspect, I think that is a red herring. There are of course religious wars regarding architectural choices, but the reason that MVP is being used in some ASP.NET projects is that there are quite a few who felt the traditional ASP.NET stack was too tightly integrated between the UI and the Business Logic. (I'm one of them.) For small projects that tight coupling isn't that big of a deal, and contributes to the quick "bring it up and running" ability of the form designer with databinding. In large projects, the limitations of these tools show up in a hurry, and having a "middle" tier hacked back in after the fact is a challenge: one you don't have to face with MVP.
I did an ASP.NET project using MVP last year. Yes, I was able to cover more with unit testing than I could before in the webforms world, but it felt hacky. Also, try explaining what you are doing to someone else. For some reason, people have a hard time grokking it. If I had to do it over again, I'd go with the ASP.NET MVC framework, since it is officially supported with tons of documentation and buzz, and not just a hack.
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...)
I was using a CASE called MAGIC for a system I'm developing, I've never used this kind of tool before and at first sight I liked, a month later I had a lot of the application generated, I felt very productive and ... I would say ... satisfied.
In some way a felt uncomfortable, cause, there is no code and everything I was used to, but in the other hand I could speed up my developing. The fact is that eventually I returned to use C# because I find it more flexible to develop, I can make unit testing, use CVS, I have access to more resources and basically I had "all the control". I felt that this tool didn't give me confidence and I thought that later in the project I could not manage it due to its forced established rules of development. And also a lot of things like sending emails, using my own controls, and other things had their complication, it seemed that at some point it was not going to be as easy as initially I thought and as initially the product claims. This reminds me a very nice article called "No Silver Bullet".
This CASE had its advantages but on the other hand it doesn't have resources you can consult and actually the license and certification are very expensive. For me another dissapointing thing is that because of its simplistic approach for development I felt scared on first hand cause of my unexperience on these kind of tools and second cause I thought that if I continued using it maybe it would have turned to be a complex monster that I could not manage later in the project.
I think it's good to use these kind of solutions to speed up things but I wonder, why aren't these programs as popular as VS.Net, J2EE, Ruby, Python, etc. if they claim to enhance productivity better than the tools I've pointed?
We use a CASE tool at my current company for code generation and we are trying to move away from it.
The benefits that it brings - a graphical representation of the code making components 'easier' to pick up for new developers - are outweighed by the disadvantges in my opinion.
Those main disadvantages are:
We cannot do automatic merges, making it close to impossible for parallel development on one component.
Developers get dependant on the tool and 'forget' how to handcode.
Just a couple questions for you:
How much productivity do you gain compared to the control that you use?
How testable and reliant is the code you create?
How well can you implement a new pattern into your design?
I can't imagine that there is a CASE out there that I could write a test first and then use a CASE to generate the code I need. I'd rather stick to resharper which can easily do my mundane tasks and retain full control of my code.
The project I'm on originally went w/ the Oracle Development Suite to put together a web application.
Over time (5+ years), customer requirements became more complex than originally anticipated, and the screens were not easily maintainable. So, the team informally decided to start doing custom (hand coded) screens in web PL/SQL, instead of generating them using the Oracle Development Suite CASE tools (Oracle Designer).
The Oracle Report Builder component of the Development Suite is still being used by the team, as it seems to "get the job done" in a timely fashion. In general, the developers using the Report Builder tool are not very comfortable coding.
In this case, it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background.
Unfortunaly the Magic tool doesn't generates code and also it can't implement a design pattern. I don't have control over the code cause as i stated before it doesn't have code to modify. Te bottom line is that it can speed up productivity in some way but it has the impossibility to user CVS, patterns also and I can't control all the details.
I agree with gary when he says "it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background" but also I can't agree more with Klelky;
Those main disadvantages are:
1. We cannot do automatic merges, making it close to impossible for parallel development on one component.
2.Developers get dependant on the tool and 'forget' how to handcode.
Thanks