Is it considered poor design to create "black box" User Controls that communicate directly with the service layer (to perform CRUD operations, validation, etc)?
By "black box", I mean that they retrieve/persist data independently of the page they are hosted on (using IoC injected services). Each UC can be dropped onto a page and it will just work. Mind you, there is no business logic embedded in any of these UCs whatsoever (that's all in the Domain layer).
This approach was driven by two factors:
Our application has many pages that are essentially variants on the same view (with slightly different layouts).
Furthermore, our UI designer is fond
of allowing discrete parts of a page
to be opened up for editing. Click
here for a poor attempt at
illustrating this concept.
Anyway, it felt like giving the UCs the ability/responsibility to render and persist themselves would do away with quite a bit of code duplication.
If this approach is indeed considered "icky", please feel free to suggest an alternate one that is more appealing (perhaps MVP?) I'm stuck with WebForms for the foreseeable future.
Thanks!
Assuming you correctly implement the MVP pattern for each control in this fashion this is perfectly acceptable IMO.
Personally the way I have solved issues like this is allowing my MVP pattern to have hybrid view presenters that can access many views (think IListView, IEditView) however this would be more problematic to do if they're truly user controls since they half exist outside of the page to start with. If they're user controls with their own tags you can either implement it the way you asked in your quesiton or you need to expose all the possible events to implement the code on your pages.
No, this is actually how one goes about doing good SOA, where you have "stacks" that are relatively tightly coupled horizontally, loosely coupled with other "stacks" of functionality. The stacks are tied from the UI down to the persistence layer. Think how Amazon and EBay have pages, each page is a composite UI, each piece of the UI is independent of the other pieces, but within each piece the layers are dependent upon one another.
Related
whats a preferred pattern for designing a web application using asp.net where the UI can be easily modified or totally swapped out for another ui?
I dont mean using CSS to change the lipstick on the app, but if i was to use agile development to produce proof of concepts that i can re-use moving forward with application development... i want to prevent, or limit as much as i can, the possibility that a change in the requirements that makes modifications to the UI will derail the development efforts put in up till then.
i was planing a service bases solution similar to SOA but wanted to vet my idea and check to see if i was missing anything that may suit this project better?
ASP.NET MVC would seem to fit your broad requirements.
http://www.asp.net/mvc
A service-based solution will mostly help you if you have a system that is consumed by multiple clients, which need to share common data or functionality. Otherwise, I don't see its benefit to you as it pertains to the question.
You'll probably want to leverage user controls and different classes that resolve different business objectives. Look into separation of concerns design pattern.
I have to disagree with DaveRead (I don't really trust unripe MS technologies, and MVC is still very new and not mature, in my view), and with Kon, in the sense that SOA solution is not just for multiple clients, but in my opinion it's a viable solution to (almost) any application.
but Kon rightly mentioned separation of concerns, which, if implemented correctly, should achieve just what you need.
A good rule of thumb is- when designing / coding your back-end layers, ask yourself: If I made a so-and-so change to the UI- would I have to change my back-end?
the answer, of course, should always be 'No'
good luck.
I am a strong believer in DataBinding. It will allow you to keep the UI separated from the underlying logic and data. Changing the UI or Logic, or Data can be done with a minimum impact in the overall coherence of your website / application.
This image shows how Source and UI elements are seen as two separate blocks, and the Binding is the communication between them.
I have several pages of my web application done. They all use the same master page so they all all look very similar, except of course for the content. It's technically possible to put a larger update panel and have all the pages in one big update panel so that instead of jumping from page to page, the user always stays on the same page and the links trigger __doPostback call-backs to update with the appropriate panel.
What could be the problem(s) with building my site like this?
Well, "pages" provide what is known as the "Service Interface layer" between your business layer and the http aspect of the web application. That is all of the http, session and related aspects are "converted" into regular C# types (string, int, custom types etc.) and the page then calls methods in the business layer using regular C# calling conventions.
So if you have only one update panel in your whole application, what you're effectively saying is that one page (the code behind portion) will have to handle all of the translations between the http "ness" and the business layer. That'll just be a mess from a maintainable perspective and a debugging perspective.
If you're in a team that each of you will be potentially modifying the same code behind. This could be a problem for some source control systems but one or more of you could define the same method name with the same signature and different implementations. That's won't be easy to merge.
From a design perspective, there is no separation of concerns. If you have a menu or hyper link on a business application, it most likely means a difference concern. Not a good design at all.
From a performance perspective you'll be loading all of your systems functionality no matter what function your user is actually doing.
You could still have the user experience such that they have the one page experience and redirect the callback to handlers for the specific areas on concern. But I'd think real hard about the UI and the actual user experience you'll be providing. It's possible that you'll have a clutter of menus and other functionality when you combine everything into one page.
Unless the system you are building a really simple and has no potential to grow beyond what it currently is and provide your users with a one page experience is truly provide value and an improved user experience and wouldn't go down this route.
When you have a hammer, everything looks like a nail.
It really depends on what you are trying to do. Certainly, if each page is very resource-intensive, you may have faster load times if you split them up. I'm all for simplicity, though, and if you have a clean and fast way of keeping users on one page and using AJAX to process data, you should definitely consider it.
It would be impossible to list too many downsides to an AJAX solution, though, without more details about the size and scope of the Web application you are using.
I'm working on an a pretty big project right now and am trying to implement an MVP architecture. I'm starting to run across a instances where I think JQuery or Javascript might be better suited than server-side code. I'm looking for feedback on how others are implementing client-side programming into their enterprise applications. How are you structuring the client-side code and how do you determine when to use it?
Things that can make user say "wow". For example - Populating search results while user has just typed 3-4 character of search term. Just go back in past and think about Yahoo or Hotmail which used to postback to server when you clicked on "Create Message". But when google came they just did on client side without going to server. I bet you would have said "wow" to that. At least I did.
Things that can reduce server load. For example - Adding extra data entry row in HTML table, instead of doing it through round trip, Increase/Decrease of quantity etc.
These are just some example to sight. Even to do these things properly you need to go to server but that will be behind the scene using ajax. Other than this you need to select few more jquery plugins that you will use in your project. To name some are jQuery UI, jQuery Validation, jQuery AnythingSlider etc. There are too many of them.
Http://ClearTrip.com is one site that I envy for their UX. Visit their site from mobile device and you will get further clues about their UX work. Besideds just coding you need to have a person in your team who can work on these UX aspects.
Regarding how this fits into DDD: I've just recently started my journey into DDD but one hears a lot about command/query separation in that circle. Certainly if you are doing something that hits your domain (like fetching for auto-completion or certainly if you allow partial page submission to accomplish a domain command) you have to decide how it gets there and how the domain is structured to handle it.
I think two decisions are most relevant.
First, bits entirely in the browser and even those specifically in your application layer are outside your domain and thus, though covered in the layered architecture part of the DDD discussion, do not land in the entity/value/event/service, etc. discussion. If, however, you are using AJAX to interact with your application layer and in turn need to access your domain, you need to consider again two things in my mind.
(a) Are you separating commands and queries simply using different methods on your domain? Fine if you have a relatively small demand for either queries or commands and this will not seem like "noise" in your domain API. Otherwise, you have a separate bounded context...another domain modeled just for queries that your UI needs to avoid clutter on your domain. Regardless, you are doing something like JS->AJAX handler in application layer->domain (including a domain service).
(b) Is this a command or a query? Once you have (a) figured out, this lets you know where the access will land...then use the presentation layer's use case to elaborate the domain concept and put it into your ubiquitous language.
Second, you have the DTO vs direct to domain decision. This can be a religious war gathering topic, but usually the answer is "depends." I think there are cases for using DTOs and cases for not (within the same architecture)...just search for all the discussions around the topic and apply the pattern only where it adds value; I won't try to cover details here.
Hope this provides some insight or at least conversation magnet to which others will add.
I guess this question is a little too subjective. Looks like I'm just going to grab a view books on advanced javascript and study up on the JQuery library.
I have my existing web site developed using ASP.NET.
It's college management system. Now I need to redevelop it on MVC2.
What all changes do I need to do?
I am little bit aware of MVC and have done some exercises also.
Thing I know is I can keep my database intact but there will be massive changes at other places.
WHat will be the better way to minimize the changes?
MVC is a very different concept from event-oriented WebForms. There's good chance you will have to redo the frontend completely.
Try to find out if there is anything resembling data access layer and the business logic layer. If so, you can keep them (at least partially) and reuse their methods.
However, if the current application is not well structured and looks like a giant code blurb (with no layers, parts of the code talking to any other part at will, page methods going directly to the database etc.) it may have to be redone entirely.
If the application is now heavily relies on data-bound controls, you're screwed. You will have to recreate a lot of functionality by hand.
You should be able to refactor the middle tier (if you're using a multi-tier approach) into controller/model while keeping the UI intact. Once you've done that, throw away your UI and write a proper View. Try using LINQ-To-Sql for the backend.
I'm in the process of designing a solution for the company I work at (but have just resigned from) which has a very complex application process in it. The process is close to 10 steps (including T&C's and preview) and also has some very tricky UI-level business rules (mostly driven by a legacy tie-in system).
Essentially the validation is driven by what has been selected on previous forms, and not just the one directly prior.
The solution has already been decided as an ASP.NET application but the more I design the solution the more it's looking like it's going to be very difficult to achieve in a stateless environment. It's going to either end up with query string parameters, hidden variables on the page, viewState or session to pass the information around.
Then I had it suggested that I look at Silverlight, to give it a more stateful environment and make it easier to handle the passing of the parameters around.
I've never done anything with Silverlight, other than watch presentations, so I've got no hands-on experience with it, but from everything I've read I think that it does have potential to solve some of the major problems which I can see coming out of trying to do this with standard ASP.NET.
So how do I go about:
Is Silverlight a viable option considering what I mentioned above?
Pitching Silverlight to a company without any Silverlight skills?
How do you deal with the "but it requires a browser plugin" argument?
From what you're saying your problem is about keeping state between multiple pages/forms. Sessions are good for that (not so much the query params or hidden variables as those can be tampered with, just having to think about that possibility when developing your app will slow you down.) I'd recommend that as simplest all round.
However, you can also put several forms on one page and submit them together, but have it look like different pages using javascript. It wouldn't be too hard to do with any decent javascript library, but I recommend jQuery (Microsoft is adopting, over their own, as the standard for ASP.NET)
Same as the silverlight problem if your company doesn't have many skills in javascript, but at least it doesn't require a plugin.
Don't get me wrong, I love silverlight, I love it so much that when it gets market share similar to flash, I'd drop HTML/css/javascript. It just doesn't seem to fit for you though.
I currently work for a company that builds its primary LOB app in Silverlight.
Silverlight may be a good choice for what you are trying to do, but consider:
Using Silverlight won't reduce the complexity of the application.
If you're already comfortable with ASP.Net, you can deal with complex workflow using existing idioms (Session state, the wizard control, or plain old CLR objects of your own that implement a decision tree/state machine model).
If your problem is really an issue of workflow design, you can integrate ASP.Net apps with something like Windows Workflow Foundation. However, "won't reduce the complexity of the application" probably applies to this, as well; in my limited experience, Windows Workflow Foundation hasn't made building workflows simpler, either.
What you gain by having state all wrapped up in local client objects will most likely be smaller than the cost of learning Silverlight and its idiosyncrasies.
That being said, there's nothing wrong with the idea of attacking this kind of problem in Silverlight. It's just not a silver bullet or anything; Silverlight has its own data access headaches, quirky UI code idiosyncrasies, and requires wrapping your head around yet another model for developing applications.
Silverlight has a Page class that enables you to easily support navigation where you can go back to the previous page as you do in your browser. I think Silverlight pages and the navigation framework is very suitable for the kind of application you have described.
Using Silverlight enables you to create a very rich client experience. Doing that is probably also possible in ASP.NET to some extent, but I find all the moving parts in a traditional web application (HTML, CSS, JavaScript etc.) and their interactions much more complex than the Silverlight model. If you don't have experience using Silverlight you could create a simple page navigation prototype without any real logic to get a feel for the experience. If you are satisfied you could then show it to management to demonstrate the power of Silverlight. If they like eye candy you could change the visual theme of your application in an attempt to impress them. This tactic may backfire, though, if management actually prefers battleship grey.