How to make UI proof middle tier?

AaronL

While we still wait for a real "Application Browser" to be made there is still the decision whether to target the web client platform or the smart client platform and no good answer. No technology is in more of a state of flux than this. Think about it. We have clunky 'web 2.0'. Big companies pulling at the web in different directions and could come out with a new fangle platform overnight. WinForms being replaced by WPF. P&P making the Composite UI Application Block and then are replacing it with Acropolis.

From an architects perspective I want to keep all of this as far away from my 'core code' as possible. However you P&P guys don't help me do that. And in your own architectures you seem to commit the middle tier to one or the other. The middle tier I'm referring to is the "Work Controller" it's the object that controls nitty gritty state of the application. With P&P you commit to the Web Client SoftwareFactory or Composite UI Application Block and in future, Acropolis.

It's not rocket science to access the database through WCF services. And I can do my multi step transaction processing in Windows WorkFlow. And my model, a typed DataSet does a decent job as a transport between the view and the services. The step that is still tied to the UI is the Work Controller and my command handling code.

Could the same Work Controller DLL be pushed to the client in a smart client scenario or kept back on a server in a web scenario Obviously bindings would be setup different with WCF however it seems like it could be possible.

What about agile development of a web site After initial development is done in plain Web Forms and usability tests show what UI is too clunky and needs short cut keys, drag and drop etc. a Silverlight form or separate smart client utility could be used to target areas of a web application to streamline, eg Spreadsheet grid, or a invoice receipt form. Can the same Work Controller be used equally well between an ASP.NET web form and the WPF page

So why doesn't P&P create an architecture that fits all Can such a pattern not be created with out creating something that can do everything but does nothing well

Yoni Rapoport

The solution is to develop and test your application logic (work controller) in isolation, decoupled from any external framework. External implementations such as WebForms, Silverlight, WinForms, WPF etc... should be wrapped within adapters and exposed to the application layer as an abstraction. This way one implementation can be replaced with another without impacting the application code.

I fear such a framework is not being developed because of the acceptance of the "UI layer" concept and of the fact that while it should be decoupled from business logic (which is not always right) it should be coupled to a specific type of UI. So I sense there is a tendancy towards accepting the fact that if multiple UI's are required then multiple UI layers (which contain duplicate code) are necessary.

J. Ambrose Little

Using something like MVC or MVP, you can decouple your UI from your middle tier and even make your UI logic testable to an extent. I'm assuming you're familiar with this since you mention some frameworks that use it. Your question, if I understand it, is whether or not a controller or presenter could work just as well for different UI technologies (WinForms, ASP.NET, WPF, Silverlight, NextGreatThing).

I'd suggest that while I do think that some application logic could be built in such a way as to support this, what you'd end up with, in terms of UX, is not desirable. The different technologies, particularly ASP.NET vs Win client, are too different in how they manage state, how they manage UI components, and how they communicate with a persistent store. Even if you overcame these differences, you'd be left with a lowest-common-denominator interface that limits itself to UI metaphors that can be achieved in all the imagined UI technologies.

Given that computer users are becoming more and more discerning in terms of user experience, I'd suggest that your energies should be focused on choosing the UI technology that best fits your application requirements and then using that technology to its fullest to provide the best possible UX within its technological constraints. Naturally, you still want to decouple your UI from your middle tier as much as possible, but I don't think the ROI is there for trying to decouple UI logic from UI technology. I'd even say you risk negative ROI if your technological/architectural abstractions seep through into your UI due to such an approach.

Martin Platt

Aaron,

There should be no need to have a controller, from the business logic perspective being in any way coupled to the logic, or indeed implementation of that UI. I'd also say that if you do see a pattern, or technology that requires you to in some way embed UI functionality into anything other than the presentation layer, then leave it be.

I am not familiar with the patterns and practices that mention the Work Controller, but are you confusing a controller, as in the one you find in the C or an MVC pattern with a controller for business logic decisions

You should be able to have a controller, or presenter for your UI that does the specifics with the UI, whilst calling upon the business logic code to implement the business logic in a presentation agnostic manner. You should then be able to swap out the presenter logic and UI (or view) with some other presentation implementation and that be as much code as you'd need to touch.

I know that I haven't expressly asnwered your question specific to technology, but for my mind, I prefer to work with how things are to work, not what technology they are implemented in. Once you have that nailed down, you can then look for a technology that fits your needs.

Not sure why you'd want to have a pattern that does nothing well, but does everything, that sounds like over-engineering and a bad design to me !

If I can help you further, please post another message,

Good luck,

Martin.

Cristerpher

Judging from the title and content of your post, I assume that you are not talking about the MVC, but about a middle tier model (Broker maybe ).

I think the biggest obstacle in creating a truly agnostic middle tier is dealing with instantiation and state. Where should your middle tier live On the client or on the server Should it keep state or should it be stateless

It is difficult to answer these questions without knowledge of the UI that will be using the middle tier. You have to tradeoff between scalability and performance when making these choices and the end user of the application plays a big part in that decision.

The technology to 'truly' isolate the middle tier has been evolving: DCOM, .Net Remoting, WCF...

At the moment, I think WCF is the closest to what you are looking for. The premise behind WCF being that you can decorate your middle tier and define contracts that state what functionality your middle tier will provide. Then you simply provide a configuration for what ever different ways you want to expose the middle tier (web service, in-process, binary remoting, etc).

Is that along the lines of what you were asking

Cris

Martin Platt

Just to clarify things here...

I agree that the original poster would have meant the middle tier, and understand the question.

My point was regarding confusion. I don't see how it is ever good to make the middle tier aware of, or coupled to the UI. Ever.

Since WPF and ASP.NET was mentioned I thought that it was relevant to point out that the original poster could be confused about the terminology, especially as a middle tier in a good design, i.e. one that could be service oriented, could be closely coupled to presentation. MVC, and MVPs are absolutely what the poster is asking about, as he asks if we can swap an ASP.NET page with a WPF page, or a silverlight page or whatever. That's the easiest way to do it in my opinion.

Technology isn't architecture. Architecture is architecture, driven from requirements.

To choose a technology is a different question, one that requires consideration of the architecture, and hence the requirements. How does choosing an technology have anything to do with the UI

WCF, WPF, Remoting, DCOM, all technologies that are available to implement an architecture, not patterns.

The architecture, the design are all how you use these great technologies to their fullest potential by decoupling them from each other, and reducing dependencies.

If you implement a work controller in the client, then that's basically a desktop type application, if you manage it on the server, then it is more like a distributed environment. This is really dependent upon the requirements for the application. And my advice would be to decouple it such that it can be used for either, which is a fairly straight-forward process.

With regard to agile development, and switching presentations, if the application is truly decoupled, then you will be able to swap presentation as required. You have to remember though that your ASP.NET application has to be written so it is very thin, and calls into the middle tiers which have the real business logic. The ASP.NET application really should be only concerned with presentation, for it's target platforms (HTML). In this case, the ASP.NET code behind on the server would be, and could be considered a presenter in an MVP, although you could further abstract that into classes if you like.

The architecture to seperate presentation from business logic (middle tiers) is the MVP type patterns (reading at martinfowler.com). The architecture to implement your business logic is likely to be composed of a number of patterns and practices patterns that you could use to make your life easier. You wouldn't typically use WCF as a middle tier by itself, it can be used along with WWF to implement workflows, communications and such like, but is very specific to a particular area of the application. These technologies are very good, but by themselves will not automatically leave you with a good architecture or solution ultimately. That's just down to good architecture and design!

I hope this clears up a few points, and leaves you with some things to research. If you have more questions, by all means fire me another post, and I'll try and answer it more specifically.

Martin Platt.

Cristerpher

Even though the middle tier implementation can be completey decoupled from higher layers, you still need to know what the higher layers will be in order to make the design decisions necessary to implement the middle tier. Thus the reason we have multiple application blocks that overlap in lower layers.

I don't think it makes any sense to try to consider architecture without also considering the technologies available to implement that architecture. To me, the P&P blocks appear to be an attempt to acheive some architectural coherence with the technologies available. Newer technologies open new opportunites for better architectures. WCF is one of those technologies that should make generalized architectural concepts more practical.

MCV is a great pattern, but have fun writing your own controller that takes handles both web forms and win forms transparently. You have to consider available technologies in order to design meaningful (non-academic) architectures.

Cris

Martin Platt

Why do you need to know what the higher levels are All presentation does is display the outcome of applying the business rules in the middle tier. You don't need to know anything about how the data is displayed, or do anything specific in the middle tier to take into account a particular way of displaying the data.

You would have some sort of controller, or presenter to do that for the UI, take the model, and present it.

MVC is an old pattern, MVP is the more up to date, but even that has been retired as a concept in favour of two different flavours of the same. These came about because of the troubles with the MVC pattern, and I wouldn't use it either myself.

You have to consider technologies, for sure, but you don't ask which technology allows you to decouple an interface from middle tier(s), nor do you say that WCF is the way to go, then figure out what you want to do, since it might actually be a telephone, or e-mail that you need instead.

"How do I make UI proof middle tier " was the subject, of which I suggested MVP pattern, and that technology doesn't do anything for you there at all, it is only an implementation, i.e. code, which isn't where you start, or not unless you want to get yourself burnt.

So to the original poster, use that information to help you decouple, then choose the rest of your architecture, then your technology, then design, then implement.

And if the original poster has any questions, please don't hesitate to ask about it.

Martin Platt.

AaronL

The responses to my questions have been very good. For a number of reasons I haven't been able to respond until now and I apologise for not showing interest in your answers.

For MVC & MVP I've derived something similar to CAB. - Model, View, Work Controller, Service Agent. In this case the View is a form or user control including it's code behind file that implements the view interface. The work controller is only aware of a simple interface to this form or user control. The work controller is the central point that is aware of the view, model and service agent and child work controllers. Process is in the work controller, while services accessed by the work controller are mostly stateless (usually CRUD). The Process is in the form of command item classes, each class implements a different process and a work controller contains multiple command items. So the services and model are only half the business logic. The work controller and it's commands are important chunks. And for a smart client this is run locally and for ASP.Net this is run on a server.

The platforms available to consumers are really dynamic and there is increasing pressure to be able to competitively adopt a wide range of user interfaces to the same underlying distributed system. And as agile add ons and "sweeteners" rather than a new product development effort.

I agree with Martin, there really should be no reason why it isn't possible. However it is a tough thing to do. At the moment I'm focusing on the smart client side. When we do create a slice that uses ASP.Net I think we will create it independently and then afterwards see if we can refactor it back to a common work controller.