mvc which part first? - oop

I'm creating a web application using the mcv pattern.
I would like to know, from your experience and from studies in the field, from which component is believed is better to start with, the model the controller or the view?


Starting with the View may motivate you more, and is good because it helps put yourself in the mindframe of the user (always a good thing).
It will also help you realize what you really do and don't need for the Model. Simplicity of Model is quite useful, and working with the View helps you realize that. It will also help you focus on the Model-View interface, which is very important and the primary means of interactions between the two.
That said, I actually often start on the Model, because I can already envision the ideal View, and it is very easy to overdesign a View.
Iterating back and forth between Model and View works well, so as to not over-engineer them.
The concept of a Controller is overhyped; a Controller is the necessary code to make interactions between View and Model as elegant and clean as possible. It's thus something I would inadvertently make while refactoring, and would not start with (or only add to as necessary, keeping it very lean and simple).


Keep in mind that if you do your views first, you won't be able to benefit from any of the scaffolding that the MVC Tooling could do for you if you're Models were already created. This alone should motivate you to do some sort of rudimentary Model first.
I usually opt for Models first, and I find that I switch back and forth from there. The whole thing is much more iterative rather than hammer out the models to be "perfect" on the first try. But the bulk is done up front and I later go back to tweak or modify as needed when additional things are needed by the view/controller along the way. As with anything though, this can lead to some scope creep so keep a firm view of what the overall goal is and stick to that and get it done first. Anything you come across that might be a good feature to add that was not in the initial scope, write it down in detail if you can. Then later on you can go through all of the things that you wrote down and use them for the next version.


From my experience it is best to start with the model.


I would say start with the model first because the model pretty much defines what is going to be in your view. Then create controllers and create your views from the controllers.
I suppose you could start with either the model or controller.


I mostly start my projects thinking about what elements I would need.
Once I know what I want / need I'll start with the design (the static template(s)).
Once I have a static template I'll mostly know what code I'll need.
After that I'll start with the basic Controller and expand it to my needs. When I'm working on the Controller and I find something which should be placed in the Model layer I start programming the Model layer.
I think it all depends, but this works for me most of the time.
As long as you keep it all separated it's all fine I guess.
Just my two cents

Related

MVC design pattern with multiple classes in iOS

I'm trying to improve the structure of my development, and stripping back to the very beginning while learning Swift. This is not language dependent though (the edit is not appropriate).
Something has been troubling me for sometime, and I hope someone can take the time to help me.
I'm making a simple game where questions are stored in a binary tree, so am creating a class for the binary tree (BinaryTree.swift).
My ViewController will take care of interactions with the interface (buttons etc.)
I need to also create the business logic for the game (which question should be returned, keeping score etc.). The logic for this type of game is trivial, but I need to understand principles before I scale up to larger projects.
Problem
Is it reasonable to create a class in a separate file solely for the game logic (GameLogic.swift), as I'm concerned that it is not a reasonable way to structure this app.

In all honesty, it is up to the developer to choose how they structure their data. The MVC, or Model View Controller model is still alive and well but I choose not to use it. Without a who lot of information on what exactly would go into GameLogic.swift, I would say go ahead and try it. Maybe another developer with more experience than me can give you another idea!

How to use Core-Data best in complex Apps

I am a Mac App Dev and have some questions about how to use Core-Data correctly.
I have multiple TableViews and they are all playing around with the same data (which I want to save persistently with Core-Data). I know the central part of Core-Data which I have to work with - NSManagedObjectContext and I know how to create NSManagedObjects and save/edit/delete these in the persistent store.
But actually I'm wondering about how to organize all that together with multiple ViewControllers,Views,Tables,.. efficiently and without merge conflicts. I've read about some approaches for that: one was by passing the context down from the delegate through every layer of your code. Somebody else suggests to create a singleton-class, let's call it DatabaseManager, which holds the NSManagedObjectContext instance and you go and ask it from there. (I especially like this approach, don't know why.) Or just ask the delegate every time with [[NSApplication sharedApplication] delegate], does this have any disadvantages?
Okay, a lot of questions here but that was only about the How. Now I want to know about your recommendations of where I should actually do all interaction with the managedObjectsContext. (to be in compliance with MVC and don't mess up my code and make it more complicated than it has to be..)
Should I save stuff to Core-Data in my NSTableViewDelegate/-DataSource Classes directly or just fire up an Notification for someone else?
Should I implement some instance methods for my Model-Objects (like -(void)saveInstanceToDatabase,..) to encapsulate Core-Data-Interaction?
Ok thanks in advance for all the brave guys who read until this point and give me some kind of response :D I always appreciate code-examples!

After years of working with Core Data... I've come to the conclusion it's not very good. There are some serious flaws in it's design that can only be solved properly by abstracting the whole thing away.
I recommend implementing your own model for manage objects, which uses core data underneath but does not ever expose it.
Your views and controllers and application delegate and all of that should not ever touch core data at all. They should talk to a series of classes you create yourself, which has been custom tailored for your particular application.
That object layer can use core data underneath, or it might use something else like FMDB or NSCoding or even just plain old NSData objects (this is the fastest option, if you need extremely high performance with large amounts of data, especially when combined with features like NSDataReadingMappedIfSafe).
Start with Core Data. Look at the other options if you have problems. Having your own layer on top means you can easily abandon it in future. And many developers have chosen to move away from Core Data shortly after their app ships to the public. Often due to unsolvable bugs or performance issues.

Why is an object model necessary in project?

Why is an object model necessary in project?

It isn't. For example, you could use the Transaction Script without a domain object model.
An object model is recommended for most applications because object orientation is very good at dealing with complex business logic.
Even the smallest project tends to have some business logic, which may well grow, leading to many projects using an object model from day one...

Nothing is necessary is any project. You need to ask a more specific questions. For example - If I'm doing a X type of project, is an object model necessary, or can I do Y?
The context of your question is important and helps us to provide answers you can really use.

Why is any kind of planning document needed in a project? Why not just generate a file of the appropriate size filled with random numbers, select an entry point and debug from there?
Nothing is "necessary" for a project aside from some way to enter and process code. The rest is there to:
make projects easier;
get them out the door faster;
allow others to more rapidly come up to speed;
permit even you to understand it better.
There are a myriad of tools for accomplishing these aims and the object model is one of them. It permits you to more rapidly understand, through visualization, what entities there are in your problem domain and how they relate to each other. It can, of course, if used improperly (which is, sadly to say, about 99.44% of the time) instead obfuscate the design or, worse, drive it in unnecessary directions. So can if statements, however, so I don't generally view that as a strong condemnation of them.
I think a better question to ask, for future reference, would be "when are object models useful and when do they not apply?"

What techniques do you use when you are designing an Object Model alone?

So no doubt that building a domain model is something that I think happens best when you approach it as as team. Even going so far as to involve someone who is not technical and a member of the 'business' in the modeling sessions. So much can get done quickly when you put the right people in a room and hammer out things on a whiteboard. But what about the times that you don't have that luxury? What about when you have to build a complex domain model alone? I have been doing this for the past month or so and have done the following:
Start off by Noun Idendtification, then use Class-Role-Collaborations to analyze relationships
Look for analysis patterns that can be used to refine the model, Party, etc..
As soon as I have a handle on the basics, I'll bust out an IDE and start writing XUnit tests to show that the model let's me do the things that I want
While these techniques have worked well, I'm not sure they are as efficient as a truely collaborative effort. I think it is easy to get carried away with a concept only to realize later that it violates x or y requirement. What techniques have you used when working in isolation to ensure that your object/domain model is on target?

Everyone does it differently, I think, but...
I almost always start with a Class diagram (usually UML-like and on paper), paying special attention to relationships between classes and their arity. Validation at this stage is mostly trying to understand if the high-level semantics of the entities make sense together.
Then start sketching in the key functions, especially those involved in collaborations. Make sure objects in a collaboration can reach each other through the relationships. At this stage I'll be using a drawing tool (StarUML).
Then come the gedanken experiments. I mentally walk through the trickiest use cases I can think of and see if I can envision a way to address them with the given design. This isn't psuedocode, just stepping through each of the major tasks/functions and following the lines of the diagram to make sure I'm not missing callbacks, circular dependencies, etc.
I think one key is to not get too married to any particular aspect of the design until you've satisfied yourself that it will probably work reasonably well. In my mind, if you can't step through a design mentally to evaluate/validate it you either lack some understanding of the problem, or the design on paper isn't complete enough...
Then, time permitting, set that one aside and see if you can come up with something really different...

If you're building it all on your own, just make sure it's adaptable, because there's no way you'll think of everything on the first shot.
Get some big paper. Draw everything out, and be messy. Don't worry about making it perfect. Put everything down that you think of, cross out stuff as it proves to not be useful. The paper will look like your mind threw up pieces of an object model all over the place. As you think of things that have already been written down, make those things stand out. At the end of this process, you'll have a mess, but for sure you'll have a lot of good ideas. At this point, I would recommend showing this to people, but since you said that's out of the question, we'll move on.
Now sit down in front of a computer with a UML tool and map out something that resembles the highlights of your brain dump. Think of the major pieces of the object model and then think of the more minor things that enable those pieces to work together. Once you have settled on something, turn that UML into code and go about writing some tests to see if it works. Rinse and repeat.

How to convince my co-workers not to use datasets for enterprise development (.NET 2.0+)

Everyone I work with is obsessed with the data-centric approach to enterprise development and hates the idea of using custom collections/objects. What is the best way to convince them otherwise?

Do it by example and tread lightly. Anything stronger will just alienate you from the rest of the team.
Remember to consider the possibility that they're onto something you've missed. Being part of a team means taking turns learning & teaching.
No single person has all the answers.

If you are working on legacy code (e.g., apps ported from .NET 1.x to 2.0 or 3.5) then it would be a bad idea to depart from datasets. Why change something that already works?
If you are, however, creating a new apps, there a few things that you can cite:
Appeal to experiencing pain in maintaining apps that stick with DataSets
Cite performance benefits for your new approach
Bait them with a good middle-ground. Move to .NET 3.5, and promote LINQ to SQL, for instance: while still sticking to data-driven architecture, is a huge, huge departure to string-indexed data sets, and enforces... voila! Custom collections -- in a manner that is hidden from them.
What is important is that whatever approach you use you remain consistent, and you are completely honest with the pros and cons of your approaches.
If all else fails (e.g., you have a development team that utterly refuses to budge from old practices and is skeptical of learning new things), this is a very, very clear sign that you've outgrown your team it's time to leave your company!

Remember to consider the possibility that they're onto something you've missed. Being part of a team means taking turns learning & teaching.
Seconded. The whole idea that "enterprise development" is somehow distinct from (and usually the implication is 'more important than') normal development really irks me.
If there really is a benefit for using some technology, then you'll need to come up with a considered list of all the pros and cons that would occur if you switched.
Present this list to your co workers along with explanations and examples for each one.
You have to be realistic when creating this list. You can't just say "Saves us lots of time!!! WIN!!" without addressing the fact that sometimes it is going to take MORE time, will require X months to come up to speed on the new tech, etc. You have to show concrete examples where it will save time, and exactly how.
Likewise you can't just skirt over the cons as if they don't matter, your co-workers will call you on it.
If you don't do these things, or come across as just pushing what you personally like, nobody is going to take you seriously, and you'll just get a reputation for being the guy who's full of enthusiasm and energy but has no idea about anything.
BTW. Look out for this particular con. It will trump everything, unless you have a lot of strong cases for all your other stuff:
Requires 12+ months work porting our existing code. You lose.

Of course, "it depends" on the situation. Sometimes DataSets or DataTables are more suited, like if it really is pretty light business logic, flat hierarchy of entities/records, or featuring some versioning capabilities.
Custom object collections shine when you want to implement a deep hierarchy/graph of objects that cannot be efficiently represented in flat 2D tables. What you can demonstrate is a large graph of objects and getting certain events to propagate down the correct branches without invoking inappropriate objects in other branches. That way it is not necessary to loop or Select through each and every DataTable just to get the child records.
For example, in a project I got involved in two and half years ago, there was a UI module that is supposed to display questions and answer controls in a single WinForms DataGrid (to be more specific, it was Infragistics' UltraGrid). Some more tricky requirements
The answer control for a question can be anything - text box, check box options, radio button options, drop-down lists, or even to pop up a custom dialog box that may pull more data from a web service.
Depending on what the user answered, it can trigger more sub-questions to appear directly under the parent question. If a different answer is given later, it should expose another set of sub-questions (if any) related to that answer.
The original implementation was written entirely in DataSets, DataTables, and arrays. The amount of looping through the hundreds of rows for multiple tables was purely mind-bending. It did not help the programmer came from a C++ background attempting to ref everything (hello, objects living in the heap use reference variables, like pointers!). Nobody, not even the originally programmer, could explain why the code is doing what it does. I came into the scene more than six months after this, and it was stil flooded with bugs. No wonder the 2nd-generation developer I took over from decided to quit.
Two months of tying to fix the chaotic mess, I took it upon myself to redesign the entire module into an object-oriented graph to solve this problem. yeap, complete with abstract classes (to render different answer control on a grid cell depending on question type), delegates and eventing. The end result was a 2D dataGrid binded to a deep hierarchy of questions, naturally sorted according to the parent-child arrangement. When a parent question's answer changed, it would raise an event to the children questions and they would automatically show/hide their rows in the grid according to the parent's answer. Only question objects down that path were affected. The UI responsiveness of this solution compared to the old method was by orders of magnitude.

Ironically, I wanted to post a question that was the exact opposite of this. Most of the programmers I've worked with have gone with the custom data objects/collections approach. It breaks my heart to watch someone with their SQL Server table definition open on one monitor, slowly typing up a matching row-wrapper class in Visual Studio in another monitor (complete with private properties and getters-setters for each column). It's especially painful if they're also prone to creating 60-column tables. I know there are ORM systems that can build these classes automagically, but I've seen the manual approach used much more frequently.
Engineering choices always involve trade-offs between the pros and cons of the available options. The DataSet-centric approach has its advantages (db-table-like in-memory representation of actual db data, classes written by people who know what they're doing, familiar to large pool of developers etc.), as do custom data objects (compile-type checking, users don't need to learn SQL etc.). If everyone else at your company is going the DataSet route, it's at least technically possible that DataSets are the best choice for what they're doing.

Datasets/tables aren't so bad are they?
Best advise I can give is to use it as much as you can in your own code, and hopefully through peer reviews and bugfixes, the other developers will see how code becomes more readable. (make sure to push the point when these occurrences happen).
Ultimately if the code works, then the rest is semantics is my view.

I guess you can trying selling the idea of O/R mapping and mapper tools. The benefit of treating rows as objects is pretty powerful.

I think you should focus on the performance. If you can create an application that shows the performance difference when using DataSets vs Custom Entities. Also, try to show them Domain Driven Design principles and how it fits with entity frameworks.

Don't make it a religion or faith discussion. Those are hard to win (and is not what you want anyway)
Don't frame it the way you just did in your question. The issue is not getting anyone to agree that this way or that way is the general way they should work. You should talk about how each one needs to think in order to make the right choice at any given time. give an example for when to use dataSet, and when not to.
I had developers using dataTables to store data they fetched from the database and then have business logic code using that dataTable... And I showed them how I reduced the time to load a page from taking 7 seconds of 100% CPU (on the web server) to not being able to see the CPU line move at all.. by changing the memory object from dataTable to Hash table.
So take an example or case that you thing is better implemented differently, and win that battle. Don't fight the a high level war...

If Interoperability is/will be a concern down the line, DataSet is definitely not the right direction to go in. You CAN expose DataSets/DataTables over a service but whether you SHOULD or is debatable. If you are talking .NET->.NET you're probably Ok, otherwise you are going to have a very unhappy client developer from the other side of the fence consuming your service

You can't convince them otherwise. Pick a smaller challenge or move to a different organization. If your manager respects you see if you can do a project in the domain-driven style as a sort of technology trial.

If you can profile, just Do it and profile. Datasets are heavier then a simple Collection<T>
DataReaders are faster then using Adapters...
Changing behavior in an objects is much easier than massaging a dataset
Anyway: Just Do It, ask for forgiveness not permission.

Most programmers don't like to stray out of their comfort zones (note that the intersection of the 'most programmers' set and the 'Stack Overflow' set is the probably the empty set). "If it worked before (or even just worked) then keep on doing it". The project I'm currently on required a lot of argument to get the older programmers to use XML/schemas/data sets instead of just CSV files (the previous version of the software used CSV's). It's not perfect, the schemas aren't robust enough at validating the data. But it's a step in the right direction. The code I develop uses OO abstractions on the data sets rather than passing data set objects around. Generally, it's best to teach by example, one small step at a time.

There is already some very good advice here but you'll still have a job to convince your colleagues if all you have to back you up is a few supportive comments on stackoverflow.
And, if they are as sceptical as they sound, you are going to need more ammo.
First, get a copy of Martin Fowler's "Patterns of Enterprise Architecture" which contains a detailed analysis of a variety of data access techniques.
Read it.
Then force them all to read it.
Job done.

data-centric means less code-complexity.
custom objects means potentially hundreds of additional objects to organize, maintain, and generally live with. It's also going to be a bit faster.
I think it's really a code-complexity vs performance question, which can be answered by the needs of your app.

Start small. Is there a utility app you can use to illustrate your point?
For instance, at a place where I worked, the main application had a complicated build process, involving changing config files, installing a service, etc.
So I wrote an app to automate the build process. It had a rudimentary WinForms UI. But since we were moving towards WPF, I changed it to a WPF UI, while keeping the WinForms UI as well, thanks to Model-View-Presenter. For those who weren't familiar with Model-View-Presenter, it was an easily-comprehensible example they could refer to.
Similarly, find something small where you can show them what a non-DataSet app would look like without having to make a major development investment.