As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As far as theory goes it seems that Asp.net MVC framework could better be described as an MVP software pattern... Why not?
Because as it seems to me I see Asp.net MVC as a framework that has functional views (scripts running) that invoke controller actions. So it seems views are masters.
There are two distinct differences (taken from source):
Passive View:
The View is as dumb as possible and contains almost zero logic. The Presenter is a middle man that talks to the View and the Model. The View and Model are completely shielded from one another. The Model may raise events, but the Presenter subscribes to them for updating the View. In Passive View there is no direct data binding, instead the View exposes setter properties which the Presenter uses to set the data. All state is managed in the Presenter and not the View.
Pro: maximum testability surface; clean separation of the View and Model
Con: more work (for example all the setter properties) as you are doing all the data binding yourself.
Supervising Controller:
The Presenter handles user gestures. The View binds to the Model directly through data binding. In this case it's the Presenter's job to pass off the Model to the View so that it can bind to it. The Presenter will also contain logic for gestures like pressing a button, navigation, etc.
Pro: by leveraging databinding the amount of code is reduced.
Con: there's less testable surface (because of data binding), and there's less encapsulation in the View since it talks directly to the Model.
See this question: What are MVP and MVC and what is the difference?
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Why does the UIApplication class need a delegate to have "things" done on its behalf? Why can't this class do "things" directly without the need for an intermediate object such as a delegate? What is the purpose of that principle?
In the same way I ask myself: why isn't it possible to directly access the keyboard in order to dismiss it? Why is there a need for signaling the view controller as a delegate in order to resign first responder?
Delegation is a core design pattern. It allows for the seperation of responsibilities between parts of your program. The idea is that the part of your program that, for example, draws to the screen probably shouldn't be talking to your database. There are several reasons for this:
Performance: if the same object that draws to the screen access your data store, you're going to run into performance problems. Period. Full stop.
Code maintanence: it's easier to conceptualize code that is properly modularized. (For me, anyway)
Flexibility: If you subclass in your code, that's great - until you start running into monolithic classes that have all sorts of undesired behavior. You'll reach the point where you have to overload behaviors to turn things off, and your property namespace can become polluted. Try categories, delegatation, and blocks for altrnatives. As king Solomon says in Ecclesiastes, paraphrased: There's a time and place for everything under the sun.
To make it easier to write, read, iterate upon, and maintain your program, it is strongly advised that you follow certain practices. You're welcome to subclass many classes, and Apple won't reject your app for poor code, provided that it runs as advertised. That said, if you don't abide by specific tried and true practices, you're digging your own grave. Sub passing isn't inherently bad, but categories, protocols, and blocks are so fascinating, that I'd prefer them anyway.
Why is subclassing undesirable?
Subclassing isn't undesirable. It's just that it's not always the right solution, and it's often better to use composition instead of inheritance. Lots has been written on this on Stack Overflow already, to the point that your title puts this question in danger of being closed as a duplicate. Rather than trying to repeat, I'll just point to one of the more popular questions covering this topic: Prefer composition over inheritance?
Why does the UIApplication class need a delegate to have "things" done
on its behalf? Why can't this class do "things" directly without the
need for an intermediate object such as a delegate? What is the
purpose of that principle?
It provides a much looser coupling that allows Apple to change or replace the application object without breaking existing code.
Delegates are very useful but they also have their place and time. It is also very possible to go about without using delegates. There are certain instances though, where delegates are important. For instance, when you use the uiTextview delegate, it is important for the controlling class to know when the text changes so it can handle it. And, because different classes may want to handle this event in different ways (limit characters, capitalize letters, etc) its easiest to use a delegate.
You may be saying: Yes, but why not just make a subclass with desired behavior? Well, this is possible, but there are a few reasons why you should not proceed this way. Firstly, you may override a behavior that is happening before the delegate is called. Next, it can be dangerous because you might accidentally override a function which was necessary. Third, it is a lot more work and more code, so it will be harder to debug. Imagine you have a form with 100 textboxes and they all have different behaviours. you would not want to create 100 subclasses... its much easier to do a switch case and delegate appropriately.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am using entity framework in my latest ASP.NET MVC 3 project. As it is DB first, the entity framework generates Database models. In my service (business) layer I Scaffold (MvcScaffolding) to generate service methods, views and controllers. Scaffolding also generates the domain models. When binding these models to the Views, I use view models.
In short, I ended up in using three types of models. Is this Ok? The view models are kept in the Presentation layer, domain models are kept in the business layer and data models are kept in the repository layer.
Please let me know your thoughts.
That sounds fine and indeed has several benefits.
You can recreate your database models from scratch without affecting the domain models, except how they are mapped of course. Some would argue that these two could be merged into one but it deeply depends on your setup.
Separate view models will allow you more freedom to change and create new viewmodels to suit your views. It also helps preventing late loading proxies etc.
Many people would also have a Dto set of objects. These come in useful as a set of objects for caching and also if you have more than one UI, say a windows service as well.
Automapper is very popular to ease the pain of having so many models to map.
It is good when you have differences between models on every level. If all you do with this models is put data from one layer model to another layer model without any transformation and processing, you can remove redundant models. In common cases domain model becomes redundant.
You should create separated viewmodel and database model due to necessity to have a possibility to recreate database model from database without changing of views.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm new to MVC.
I have read this short bit detailing three ways of dealing with the view model in MVC:
http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx
The gist of it seems to me that:
Method 1, pull an object out the database and use it as your view model. Quick and simple, but if you want data from multiple tables you're totally screwed (I can't think of a way around it without Method 2).
Method 2, create a class that has references to multiple objects, and use this as your view model. This way you can access everything you need. The article says that when views become complicated it breaks down due to impedance mismatch between domain/view model objects... I don't understand what this means. Googling impedance mismatch returned a lot of stuff, the gist of it being that you're representing database stuff using objects and stuff doesn't map across cleanly, but you'd presumably have this problem even with Method 1. Not sure what I am missing. Also seems to me that creating a class for each View to get the data you want isn't ideal from a maintenance point of view, not sure if you have a choice.
Method 3, I am still getting my head around it, but I don't quite understand why their checkbox example wouldn't work in method 2, if you added a bool addAdditional to your class that wasn't connected to the domain model.
Method 3 seems to say rather than return the domain stuff directly, just pull out the properties you specifically need, which I think is nicer but is gonna be harder to maintain since you'll need some big constructors that do this.x = domain.x, this.y = domain.y etc.
I don't understand the builder, specifically why the interface is used, but will keep working on it.
Edit: I just realised this isn't really a question, my question is, is my thinking correct?
The problem I've run into with #2 is that I have to do one of these two things:
Include every single field on every single object on the form -- those that aren't going to be displayed need to be included but hidden.
Only include the specific fields I need but use AutoMapper or something similar to map these fields back onto the actual objects.
So with #2 I see a mismatch between what I want to do and what I'm required to do. If we move on to #3, this mismatch is removed (from what I understand, briefly glanced at it). It also fixes the problem that a determined hacker could submit values like id fields or similar when using method #2 that unless I was very careful could be written to my data store. In other words, it is possible to update anything on any of the objects unless one is very careful.
With method #3 you can use AutoMapper or similar to do the dirty work of mapping the custom object to the data store objects without worrying about the security issues/impedance exposed by method #2 (see comment for more details on security issues with #2).
You're probably right about impedance mismatch being present in both Methods 1 and 2 - it shows up anywhere you're going between objects in code and DB objects with relational mapping. Jeff Atwood writes about it, and cites this article, which is a fantastic discussion of everything dealing with Object-Relational mapping, or "The Vietnam of Computer Science". What you'll pretty much end up doing is weighing the pros and cons of all these approaches and choose the one that sounds like it fits your needs the best, then later realizing you chose the wrong one. Or perhaps you're luckier than I am and can get it right the first go 'round. Either way, it's a hairy problem.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I admit it. I am using singletons. I know what you may all say, and frankly, seeing all these answers on the Internet, saying about the bad aspects of singletons, and advising against them really made me question my programming practices.
I have already read some posts in StackOverflow regarding Singletons, but I post this question not only to ask about them, but to see some insights about the way I use them in my programs.
I feel I must really clarify some things here and ask fore directions.
So lets consider some cases where I use singletons a lot:
To create accessors to global variables, like my root view controller, specific and always existing view controllers, application state, my global managed object context... stuff like that
To create utility classes whose job is to handle data application-wide. For example, I create a Singleton that will operate my caching database, which relies on Core Data. Since I need to create caches and other stuff to be put in the database in different views, it somehow felt better to create a class that will handle database ins/outs (being careful about thread safety).
Handling network sessions. Actually, I use it to keep alive a connection and sending something like a PINg to a server each XX seconds.
I think that about sums it up. I would really like opinions from other developers on the matter.
Do you think that there are better solutions for these problems above?
Do you think that there are always better alternatives to singletons and that they should be avoided?
Is it better in terms of multithreading to forget about singletons?
Any recommendations and thoughts would be useful, and most welcome.
Singletons are certainly not always evil, but as you mention you have to be careful about thread safety (on that topic, check out this blog post on singleton initialization).
One reason why singletons are often decried as evil is that they can make it harder to "scale" parts of a program if they rely too much on a singleton and its behavior. You mention database access, a server or desktop application might start out with singleton implementation to handle all database needs and then later try to use multiple connections to speed up independent requests, etc. Breaking up such code can be very hard.
Even in an iOS application using CoreData it can be useful to not rely on a global ManagedObjectContext on your application delegate or some root view controller.
If you pass each view controller a reference to a ManagedObjectContext you can gain some flexibility. Most of the time you'll just pass the same context from one view controller to the next, but if you ever decide to in the future, you can for example create a new ManagedObjectContext for an editing view where you can use the undo features of the context but only merge the changes back into the "root" context if the user decides to save them or easily discard them otherwise. Or maybe you want to do some background processing on a whole set of objects. If everything operates on the same context, you'll end up with synchronization issues.
To create accessors to global variables, like my root view controller, specific and always existing view controllers, application state, my global managed object context... stuff like that
Singletons are globals. Wrapping a global with another global doesn't really help anything.
To create utility classes whose job is to handle data application-wide. For example, I create a Singleton that will operate my caching database, which relies on Core Data. Since I need to create caches and other stuff to be put in the database in different views, it somehow felt better to create a class that will handle database ins/outs (being careful about thread safety).
Sure, but this probably doesn't need to be a singleton. Indeed, part of the design of Core Data is that it is valid to have multiple MOCs that talk to the same store.
Handling network sessions. Actually, I use it to keep alive a connection and sending something like a PINg to a server each XX seconds.
This should be a singleton if the server might enforce some n-connections-per-user/IP-address limit. Otherwise, it probably does not need to be a singleton.
As I mention in my aforelinked blog post, the solution I prefer is to have each object own each other object. For example, your MOC and connection objects would each be owned by any object(s) that need to work with them. This improves memory and resource management (singleton objects never die) and makes the overall design of the application that much more straightforward.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Surely MDI not so bad?
I have an ERP-type app and I have chosen a MDI UI model. The reason for this is to enable the user to multitask.
Yes, many say that a user cannot multitask, but hear me out.
My app has several modules or functional areas e.g. Admin, Pricelists, Sakes Orders, Production, Stock Shipping, etc.
I chose to create a MDI parent window for the main app window with a toolbar button for each module.
So let's say the user wants to create a Sales Order. He clicks the Sales Order button on the main toolbar and the
Sales Order window appears. This is a MDI child that allows the user to create and edit a sales order and perform
some functions on it e.g. Post, Accept, etc. So, if you are in the middle of creating a sales order and you need
to change a pricelist or add some reference data you need in the SO, you simply open that module from the toolbar
without having to abandon the SO. You cannot accept the SO, because it could violate business rules.
My app is not MDI in the sense of editing more than one document of the same kind like XLS or Word. The modules each
have their own MDI child window.
Comments would be appreciated.
MDI is not bad. It is just pointless nowadays. SDI (Single Document interface) with nice docking manager and good tabs support is sufficient enough.
Look at your IDE for example. I am almost sure that it is SDI (like Visual Studio, Delphi, Eclipse, Net Beans, etc.)
There's nothing wrong with MDI if you have good reasons for doing so. However, the reasons you have expressed are not really valid reasons to choose MDI in my opinion. You can just as easily do what you want with SDI popup windows, so long as they are non-modal.
The disadvantage of MDI is that it doesn't work very well in multiple monitor situations. The advantage of MDI is that it provides lots of nice child window management features (ctrl-tab, etc..) that you would have to emulate in SDI.
I'm not saying that MDI is bad, or that it is bad for your circumstances, but simply being able to work with more than one window at a time is not a reason to choose MDI.