we have a rich client application written in WPF/WCF and are intending to create a companion website in ASP.net (using MVC if possible).
I've been asked to figure out how much of our current codebase, we can reuse (by a separate team) - and I have little to no experience with ASP.net.
We will reuse our domain model, but is there any point in separating out the WPF-specific parts of our ViewModels and reuse the WPF-agnostic parts in MVC? Does it even follow the same paradigms? We use RelayCommands exclusively for commanding, so it would be easy to wrap the contained methods in something ASP.net specific... But how about UI-specific things - e.g. does ASP.net use INotifyPropertyChanged - or how does it handle UI-updates?
For me it wouldn't make any sense. Your models should contain all of your important business logic code and should be the point of greatest reuseability. Your view models should contain presentation logic only, and as this is so different for a desktop and web app, it doesn't make sense to reuse these.
MVC does not use any binding mechanism for UI updates, as web apps are stateless by nature. You will actually most likely end up using view models for your MVC app, but in MVC these act as simple data transfer objects (DTOs) for providing data to the views for rendering for each HTTP request. Once the view is rendered, you would need to go back to the server to update the view model and rerender the view.
Alternatively, you can of course update the UI client side with scripting. Knockout.js is a nice JS library for client side view model/view binding.
I can't directly answer your specific question because it depends highly on your application and the way your existing view-model is written but the question you raise is an interesting one.
On the one hand, the logic that the view-model contains very little view-specific code is a tantalizing argument for reuse. On the other hand, the view-model very clearly serves the needs of the view and expecting it to serve the needs of a different view could be problematic.
In the end all we can give are guidelines. You certainly don't want a monolithic view-model with ifdefs or ifs all over the place. You could refactor common functionality into base classes -- that's the object-oriented way -- but without good unit tests it's sure to break something in your already working code. But not doing that means having distasteful cut-and-paste code that is almost the same and likely to diverge creating a maintenance nightmare.
Perhaps a practical approach is to assume you'll need a whole new view-model but to review your existing view-model for code you can push down into the model before your start, thereby making the view-model as small as possible. Then at some point, maybe after you get a prototype working, you could attempt a merge to see if it is practical and what issues arise. If it can work, take those issues into account as you continue implementation and then plan the two tasks according to your needs.
Related
Is it good practice to combine MVVM [angularjs,knockout.js]with MVC [JSF/spring].
Is it good way to control mvvm object/variables/ from inside JSF page.
Lets say I have to update a dropdown list in angularjs model by using jsf controller to fetch list object and update angularjs dropdown model. Is this a clean way or a junk way or is it just a work around.
I have to admit that I don't really know JSF or Knockout. However, I can easily imagine that because both sides want to be in charge of viewed components, a component based framework like JSF or Wicket might have trouble playing together with Angular. A couple things come to mind:
Why do you need the component framework from the server side? Why not use a request-based framework like Spring MVC or struts? They should work fine as they are just taking care of the overall page loading.
You will probably be ok if you decide to use one technology to do one thing. For example, do your page containers with JSF, and everything inside the page with Angular. I think you'll be ok with that. Of course, you are losing a big part of the benefit of JSF.
I'm actually doing this right now. I can't say what the best practice is, but we found that we needed to be able to output dynamic HTML from the server, even if you have an MVVM framework in the front end. Things like internationalization is better handled on the server side, and with purely static HTML from the server you run into a lot of limitations.
The main drawback is complexity. You will have controllers, models and views on the server, combined with controllers, templates and viewmodels on the client. This makes the architecture a bit confusing, especially as you bring new members into the team, so documentation and code structure becomes very important.
Overall, I think it's a valid approach. It hasnt bitten us yet, at least :)
When I gloss over the backbone.js site, I'm not sure what is it trying to do.
It seems somewhat popular, but why should I want to learn it? What will it do for me? Why was it made? What problem does it solve?
I find the question perfectly valid and from my point of view there is nothing wrong with inquiring about the potential use cases of a library/toolkit.
What Backbone.js does (so do several other javascript mvc implementations) is that it provides a means of organizing the code into a modular pattern known as MVC pattern which is all about separating your code into three loosely coupled layers:
Model layer dealing purely with data and associated operations
View layer being the presentational aspects
Controller layer being the binding glue layer
(different frameworks deal with this differently : Backbone implementation of controller layer comprises of client side routing capabilities).
So, on the whole backbone provides you an infrastructure using which you can deal with data through models which contain encapsulated within them the data and associated validations, which can be observed ie. you can bind events to change events.
The View layer is mostly left for the user to separate the ui into manageable isolated sections.
Here are some problems that Backbone solves for me in the JS/HTML space:
Separation of Concerns (SoC)
Composability
Testability
Component Model
Abstraction
That is not to say that this is the ONLY system that does this. There are others. Backbone does a pretty good job of helping with these things, though.
From backbonejs.org
It's all too easy to create JavaScript applications that end up as
tangled piles of jQuery selectors and callbacks
And that's exactly what backbone does, a series of callbacks on model changes and jQuery selectors to bind events.
So to answer the question, it solves nothing only to provide a way (the backbone way) of structuring code with some slight automation in the REST side of things.
I'm confused about the architectures which we can use to develop a business application with WPF 4.0 and EF 4.0 technologies.
My first choice was a traditional N-tier architecture contains: UI, Business Logic Layer & Data Access Layer with a disconnected behavior.
In this way I create 3 project for each layer and another project for my Entities/DTOs (Each layer is an assembly). Each layer references only to it's upper and lower layers (That is: UI can see the BLL but can't see the DAL). But all layers have access to the Entity/DTOs assembly for communication purposes.
The problem starts when I want to create a simple CRUD form with a DataGrid for example. The BLL disposes the DataContext of the DAL when returns an Entity/DTO, this is the reason that forced me to use STEs. But yet there are several problems. For example I should call "StartTracking" method for each entity returned from BLL to the UI. In short, I don't sure about this pattern reliability or I think I have to forget about automatic handled CRUD forms.
I use the repository model in my DAL layer but when I search about the repository pattern I find it different. It seems that it's not bad to reference to both of the DAL/Repository and the BLL/Services(Not WCF nor WebServices) layers from the UI and thus we can have a connected environment (Without using STEs).
I see an example in which we can get a person from repository but do something on it using BLL or services:
UI CODE:
var person = new PersonRepository().GetPerson(10);
Bll.Salary.PaySalary(person);
-or-
var person = new PersonRepository().GetPerson(10);
Bll.Person.MarkAsAbsent(person);
Or something like that...
With this pattern we can send the Entities/DTOs to the UI in a connected way while the DataContext is alive.
I don't know if I understand the way of using the repository pattern in big projects. I think it's not clear to naming the BLL or services classes and methods in this way. More over the developers might be confused about where to use the repository methods or BLL/service methods or about where to create the methods (in repositories or BLL/service).
I prefer the N-Tier architecture using a good approach to track the Entities/DTOs changes automatically like STEs.
Would you please recommend the best pattern in such situations or/and reference me to some good books or documents about that.
I put together a sample app that may help with some of your questions. You can review the presentation notes and the sample via my blog post here:
http://blog.alner.net/archive/0001/01/01/wpf_ef_4_sig_presentation_2010.aspx
The sample shows using STEs and includes some helpers to make the Entity Framework STEs work better in a desktop client app.
Repositories are there to hide the details of how you get the data. The idea is that you could swap the implementation of a repository from one that uses a local database, to one that uses a remote web service without the upper layers knowing about it.
Maybe the article Architecture for WPF applications is any help for you.
You might have a look at the BookLibrary sample application of the WPF Application Framework (WAF) as well. It shows a WPF MVVM application together with the Entity Framework applying the described architecture.
I've been playing around lately with Entity Framework, WCF RIA Services, and Silverlight 4. I'm impressed by how rapidly you can develop an application with these tools, and you get a lot "for free", such as the Silverlight UI automatically knowing about certain validations that are included as DataAnnotations on the EF model. However, it seems like in a large application it would be undesirable to have a dependency on EF pushed all the way through the entire application including the business logic and UI.
I know that you can use POCO / IPOCO with Entity Framework, and that is certainly an option for me. However, if you go that route, you lose some of the "automagic" stuff such as Silverlight being able to show model validations without any extra work.
How are people dealing with this? Do you give up some of the power and put interfaces in between the different layers in order to decouple the other layers from EF? Or do you give up on decoupling in order to allow for more rapid development? Is there some way to have my cake and eat it too that I'm not seeing?
My group is currently dealing with this exact issue. We came up with a decent compromise that everyone was happy with. Keep in mind that before it is all over with, projects become more complicated over time and maintainability is key. You also want to increase code reuse as much as possible so replacing your UI (or unit testing) is a minimized effort.
Given all this, we favored a well defined domain layer instead of pushing EF all the way through to the UI. This makes the model the heart of the application and doesn't force us to conform to the schema of our database. I know EF tries to abstract that away with its conceptual model, but we kept running into little gotchas that made it more and more difficult to rely on EF for the full stack. For instance, there really isn't a great place to put business logic with EF. We didn't want to put that stuff into Interceptors and we didn't want to put it in the UI. Sure, there might be a clever workaround for this, but we weren't liking the direction we were being pushed.
The compromise was to use EF but to keep it between the data store and the domain model. This way we still don't have to program against DataReaders, and we can leverage the benefits of self-tracking entities in the domain. We then expose basic WCF services (not RESTful) from our domain to our UIs.
To us, the extra validation work wasn't really THAT big a deal. Sure, our initial release takes a little more time, but the overall maintenance cycle doesn't take as long because we aren't finagling with the complexities of the framework.
I've recently asked a question on StackoverFlow about the MVC: Can the MVC Design Pattern / Architectural pattern be used in Desktop Application Development?
Based on the answer provided I started research on how this would be implemented in a Windows form Application. I came upon the following CodeProject article: http://www.codeproject.com/KB/cs/model_view_controller.aspx
In the comments below the article, certain users argue that (although this is a good article) it is actually the observer pattern. First, but less important, question is does anyone agree or disagree with that and why?
Regarding the second and more important question: I'm trying to build a small task list program in .NET. It will be very tiny and hopefully fast. In general, what would be a better architecture for such a project? The Observer Pattern or the MVC Pattern? Or another pattern?
Thank you
usually the model in an mvc (http://en.wikipedia.org/wiki/Model-view-controller) is an observable/subject (http://en.wikipedia.org/wiki/Observer_pattern#Subject), while the views are observers (http://en.wikipedia.org/wiki/Observer_pattern#Observer). also see: mvc in http://webcourse.cs.technion.ac.il/234321/Winter2005-2006/ho/WCFiles/08-Design-Patterns.ppt
(The article is not an example of MVC AFAIK for the simple reason that there is no controller.. it is more close to .net data binding if you ask me.)
MVC is not the Observer pattern. MVC is concerned with separation of concerns. The Model, the View and the Controller all do one job and trust the others to do theirs. In a way, the Controller 'directs' the view and tells it how to react to a change (Pure MVC). The controller also interacts with the model appropriately (whose responsibility is to encapsulate data and enforce constraints/rules). In MVC, the controller is the starting point for all activities - user input is received by the controller first.. However there are variants like MVP, where the user is input is received by the view first and then pushed/synched with the presenter.
The Observer pattern is where you want to watch another object for a change in state. So you could say .net events follow the observer pattern
If its really tiny, forget about patterns and just code it up without worrying about the architecture... Follow the heuristics/principles of good design
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
http://mmiika.wordpress.com/oo-design-principles/
If you run into design issues or it starts to get all messy, then bring in the pattern battalions.
I would agree that the article is not MVC. Its more of an implementation of observer pattern. Observer pattern in .NET can be implemented by using events, which was the case of the article.
MVC requires a controller class that controls what action to execute upon a request made from either the model, or the view. Applying MVC is a very good programming practice as it greatly promotes separation of concern. You will have a cleaner, more extensible, and more testable app with mvc. Another point to note, you can still apply observer pattern to an MVC app. They will not contradict each other.
===========
To answer your second question: which pattern is the best? I think the way you approach software development is rather wrong. You shouldn't worry too much about those things yet, not until you've hit a problem. e.g. If this object changes state I need these other objects to react to it, hence I would implement an observer pattern.
If I were you I would start on the model side first, and then takes things from there.