Related
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
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?"
Let's say I've made a list of concepts I'll use to draw my Domain Model. Furthermore, I have a couple of Use Cases from which I did a couple of System Sequence Diagrams.
When drawing the Domain Model, I never know where to start from:
Designing the model as I believe the system to be. This is, if I am modelling a the human body, I start by adding the class concepts of Heart, Brain, Bowels, Stomach, Eyes, Head, etc.
Start by designing what the Use Cases need to get done. This is, if I have a Use Case which is about making the human body swallow something, I'd first draw the class concepts for Mouth, Throat, Stomatch, Bowels, etc.
The order in which I do things is irrelevant? I'd say probably it'd be best to try to design from the Use Case concepts, as they are generally what you want to work with, not other kind of concepts that although help describe the whole system well, much of the time might not even be needed for the current project. Is there any other approach that I am not taking in consideration here? How do you usually approach this?
Thanks
Whether DDD, or not, I would recommend with determining the ubiquitous language (UL) by interviewing the product owner(s). Establishing communication in a way that will have you and the product owners speaking the same language not only aides in communication, but being able to discuss the project in common terms tends to help the domain model define itself.
So, my answer is basically to discuss, listen, and learn. Software serves a need. Understanding the model from the viewpoint of the experts will lay the solid groundwork for the application.
I'd start by a drawing a class diagram with all the relationships and implement only the classes that are necessary according to the requirements of your application.
You can use an anemic approach (attributes plus getters and setters) to keep things simple and avoid the step of writing business logic in the same step. With an anemic model, the logic would go into a corresponding Service class. That way you can consider Use Cases later on.
I know some people don't appreciate this way of doing things but it does help with maintenance and avoids some dependency issues.
Answer to devoured elysium's question below:
In terms of analysis, starting with Use cases (What) and then proceeding to the class diagram (How) sounds like a good rule of thumb. Personally, I'd do the Sequence diagram (When and Who?) afterwards, as you'd need to know between which processes/objects messages need to be sent.
Beyond that my take on things is that UML is simply a way to model a system/project and not a methodology by itself (unlike Merise, RAD, RUP, Scrum, etc.). There is nothing stopping someone starting off with any diagram as long as they have the sufficient information to complete it. In fact, they should be done simultaneously since each of the diagrams is a different perspective of the same system/project.
So, all in all it depends on how you go about the analysis. During my studies I was taught the rigid waterfall approach, where you do a complete analysis from start to finish before producing some code. However, things can be different in practice, as the imperative might be to produce a working application in the least time possible.
For example, I was introduced to the Scrum methodology recently for an exercise involving the creation of a web site where people can post their fictions. As there was a time constraint and a clear vision of what should be achieved, we started right away with a bare bones class diagram to represent the domain model. The Use cases were then deduced from a series of mock screens we'd produced.
From memory, the classes were Story, Chapter, User and Category. This last class was phased out in favour of a more flexible Tag class. As you'd imagine, the complete class diagram of the existing project would be much more complex due to applying domain driven design and the specificities of the Java programming language.
This approach could be viewed as sloppy. However, a web site like this could easily be made in a couple of weeks using an iterative process and still be well designed. The advantage an iterative process has over the waterfall approach is that you can continually adjust requirements as you go. Frequent requirements changing is a reality, as people will often change their minds and the possibility of producing a working application after each iteration allows one to stay on course so to speak.
Of course, when you're presenting a project to a client, a complete analysis with UML diagrams and some mock screens would be preferable so they have an idea of what you're offering. This is where the UML comes in. Once you've explained some of the visual conventions, an individual should be able to understand the diagrams.
To finish off, if you're in the situation where you're trying to determine what a client wants, it's probably a good idea to gradually build up a questionnaire you can bring with you. Interviewing a person is the only way you can determine what concepts/features are really needed for an application, and you should expect to go back in order to clarify certain aspects. Another tip would be to do some quick research on the web when you're confronted with a subject matter you're unfamiliar with.
In your example, this would be to go through the basics of anatomy. Among other things, this will help you decide what the model should contain and what granularity it should have (What group of organs should be considered? How precise does it need to be? Do only the organs need to modeled or should they be decomposed into their constituents like tissues, cells, chemical composition, etc. ?).
I think the place to start would be whatever feels logical and comfortable. It's probably best to start with the use cases, as they give you clear direction and goals, and help you avoid YAGNI situations. Given that you should be trying to develop a strong domain model, it shouldn't really matter, as the whole picture of the domain is important.
I would like to share my experience for such type of situations. I usually start with writing tests and code. And try to cover one end to end use case. This gives me fair enough idea about problem and at the end I also have something working with me which I can show case to my client. Most of the time subsequent stories build on top of previous one, but it also happens to me that subsequent stories require changes in the previous model I came up with. But this does not impact me as I already have good test coverage. In this way I came up with the model which fits for the current problem, not the model which maps the real world.
You start with Business Requirements which can be formalized or not. If formalized you would use Use Case Diagrams.
For example here are use case diagrams for an e-commerce app:
http://askuml.com/blog/e-commerce/
http://askuml.com/files/2010/07/e-commerce-use-case.jpg
http://askuml.com/files/2010/07/e-commerce-use-case2b.jpg
From these use cases, you can naturally deduce the business entities: product, category of product, shopping cart, ... that is start to prepare class diagrams.
This is best practice in many methodologies but this is also just common sense and natural.
Short answer
Pick a use case, draw some collaboration diagram (and a class diagram) to realize the domain objects involved. Concentrate only on those objects participated in order to accomplish use case goal. Write TDD test case to set the expectation and gradually model your domain classes to meet the expectations. TDD is very helpful to understand the expected behaviors and it helps to get the cleaner domain model. You will see your domain evolve gradually along with the TDD expectations.
Long answer
My personal experience with DDD was not easy. That was because we didn't have necessary foundations in the first place. Our team had many weak points in different areas; requirements were not captured properly and we only had a customer representative who was not really helpful (not involved). We didn't have a proper release plan and developers had a lack of Object Oriented concepts, best principles and so on. The major problem we had was spending so much time on trying to understand the domain logic. We sketched many class diagrams and we never got the domain model right, so we stopped doing that and found out what went wrong. The problem was that we tried too hard to understand the domain logic and instead of communicating we made assumptions on the requirements. We decided to change our approach, we applied TDD, we started writing the expected behavior and coded the domain model to meet the TDD's expectations. Sometimes we got stuck writing TDD test cases because we didn't understand the domain. We straight away talked to the customer representative and tried to get more input. We changed our release strategy; applied agile methodology and release frequently so that we got real feedback from the end user. However, needed to ensure the end user expectation was set at the right level. We refactored based on the feedback, and in that way the domain model evolved gradually. Subsequently, we applied design patterns to improve reusability and maintainability. My point here is that DDD alone cannot survive, we have to build the ecosystem that embraces the domain, developers must have strong OOP concepts and must appreciate TDD and unit test. I would say DDD sits on top of all the OOP techniques and practices.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I work at a web development shop so naturally we deal with user profiles. When dealing with one of our sites I noticed that there was no 'User' class, which struck me as odd since we certainly have users. Instead the site relies on interacting with DataRows (this is C#) returned through static methods with little to no instantiation. I asked my boss about creating a class for users and his response was that since the objects have to be rebuilt so much its often not worth it.
I am relatively new to web development and it does seem like a bit of a waste to have to instantiate objects each time the page is rebuilt but on the other hand I've always found object oriented programming to be useful. So I'm curious for some opinions, how much do you guys use OOP in web development?
The only time I don't use OOP is when:
I'm creating a simple project to test some logic. This usually leads to creating the right classes...
I'm using Classic ASP (been awhile, thank god).
I'm not programming.
edit
3+ years after posting the above; I'm appending a bit to my answer.
OOP is great and allows us a tremendous amount of flexibility for having multiple systems interacting with the same data / logic. However, there is certainly a situation in which you wouldn't want to bother loading up a lot of objects.. Namely, when you are simply pulling data for tabular display.
Querying a database and getting a simple record set back that is immediately emitted to the browser usually doesn't need OOP involved. As a matter of fact you might want to sidestep OOP completely as tabular data usually involves a roll up of other information (sums of child records) and you normally don't want to pull more data from the database than what you are actually using. ie. if you are only showing the name and email you probably don't want to grab the user name as that is just wasted cycles.
Now, putting information into a DB usually involves making sure that certain business logic is followed. For example that the username follows certain rules. In those situations leveraging an OOP style keeps things a bit more encapsulated and easily transferred between systems.
So, looking at the specific example: I wouldn't bother with more than handing a datatable to a repeater when pulling data; but I would have a user class for when I'm going to create a new one or operate on that user to make sure the business rules are properly followed.
One question: does the data need to be coupled with function/method calls? If not, OOP is not necessary.
Your best approach might be to find an empty whiteboard, create a high level model using Object Oriented Design, then with Functional Design, then with Procedural. You might surprise yourself (and others) with the results. The same language can be used in vastly different ways depending on the project. As mentioned by #wj. OOP is just a paradigm, don't be afraid to step outside of your comfort zone and design using a different paradigm.
Taking time to design using different paradigms will also help you when you approach your boss to discuss why you should or should not use the current paradigm. Most bosses will appreciate that you spent the time to research before approaching them with an idea -- this isn't to say they'll accept your idea, but being knowledgable going in will potentially get you a few extra minutes of his/her attention.
IMHO (don't take this personally), "Object Oriented Programming" has fallen with the likes of "Web 2.0" -- a buzzword of sorts, which is unfortunate; you now see developers forcing OOP where it would be better suited to use FP or PP.
The best professional advice I can give is to design (high level at first, then dive down) in multiple paradigms (do your best not to be biased -- keep an open mind) and decide which one best addresses the way your application works. In my 15 years experience, 75+% of the time I find OOP to be unnecessary, although my current project is strictly OOP.
A more important/relevant question would be, "Does Object Oriented Design have a place in my current web development?"
Although objects make it easier for some programmers to develop, I've read the perfect example of how to build an entire website without OOP. Not once ounce. Check out the last page in a 20 page series entitled Clean PHP:
http://okmaya.com/clean-php/clean-php-step-20/
Super easy to follow, clean way of building an entire website. No confusing OOP, no super nested folder, no crazy spaghetti code to follow for hours... Just simple, clean, and well laid out functions that do EVERYTHING you need, without the use of OOP. And this example has everything from login/registration credentials, an admin section (CMS), even database fixtures to get you started, a search function that uses mapquest API to do zip code / lat-long lookups... I mean it has EVERYTHING for a core project, or website.
Why bother with OOP? Clean, and properly structured procedural code is great!
On the topic of OOP. I remember another fad that everyone thought it was cool, and everyone did it, but then found out that smoking gave you a whole bunch of problems.
Stick to the simple, stick to what you know. Be an expert in PHP and you never have to depend on a framework again. Don't get me started with OOP MVC Frameworks. Interpreted languages for the web were never meant to be OOP. OOP just adds another layer of complexity. Stop being lazy. Use your PHP, and learn how to freakin program!
On the other hand, I can see how making games on a console can be difficult without OOP. But then again, it's apples an oranges. Console games keep their objects in memory until the game exits, or object is destroyed from within game. Think about it... Why do they have a loading bar in front of every level? Now, imagine a web page that has to show you a loading bar every time it loads because it has to create objects from a database. SLLOOOOOOWWWWW central! And once you navigate away from this page, you have to start all over again.
Web pages are applications within themselves. It's like rebuilding your drag racer each time you go to the starting line, only to take it apart at the finish line. WTFridge? Seriously? Hey, super geniuses who think OOP is sooo cool... Keep your damn OOP out of my websites!
Just saying, this is from my 10+ years experience with web development, you know when we used to code pages in HTML, one by one?
OOP is nothing more than a programming paradigm !! but his importance is that hi is THE actual paradigm in use implying that all modern knowledge and best practices in software engineering will be expressed following this style of programming ...
A good example in your case (web development) is the Core J2EE Patterns.
(source: sun.com)
Of course it does. You (and more so your boss) say "rebuilding" like it's a huge chore.
What you mean by "rebuilding" is running the program. Tell your boss that OOP in general is stupid because even in a desktop environment every time somebody runs a piece of software the objects need to be rebuilt so it's not even worth it.
Boss's comment is useless. The .net framework consists of objects and nothing else. A "response" is an object, even in "classic ASP" - why would people have implemented it if that were resource ineffective?
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.