After spending a not-insignificant amount of time converting a page that used concatenated html, like
string output = "";
output +="<ul>";
foreach(MyClass item in MyItems)
{
output += "<li>"+item.Name+" - "+item.SomeProperty.ToString()+"</li>";
}
output+="</ul>";
literalPlaceHolder.Text=output;
to use the ListView control, I've just discovered that the original developer went back and converted the page back to using concatenated html. My personal feeling is that listviews and repeaters lend themselves to cleaner, more informative markup that can be edited by someone with less experience with C#, and that they are faster and use less memory. At the very least the page should be using a StringBuilder instead of a string. Anyone have a good argument for this? I have a feeling it's going to cause a major conflict when I bring this up.
I disagree with the answer above.
First on a technical point of view.
Using concatenated strings in the codebehind is clearly mixing the View with your Logic. If I would browse this application, I would wonder where the output html comes from, since the aspx (or ascx) would be empty.
Furthermore, if you are using controls like the Repeater and he is concatenating html code and just outputing it to the page, there will be no consistency between the different areas of your app, and it will just become a mess to know where to look at when a bug comes up, or when a feature has to be added.
I would suggest you simply ask him why he prefers to concatenate Html. What are his reasons to switch back your code to his way of doing without asking first.
I also disagree on a team-work point of view.
In a team, Communication is everything. Without communication, you're vowed to fail. Don't fear to communicate. when there is a question, you have to ask it and you have to make things clear. whether you win or he wins is not the point. the point is to understand eachother and to work as a team, together, not against eachother.
First of all, I think it's not very cooperative for another developer to just replace your code like that, with no discussion. You will definitely have to make a good case for your position if you want to prevail in this one.
I agree that the standard ASP.Net controls are easier for less-experienced developers to deal with, if that is a concern in your situation.
I'm not sure I agree with you about StringBuilder, which has often been the source of raging debates here and elsewhere. If your list is not lengthy, there may not be sufficient justification for a StringBuilder here.
One aspect that a seasoned developer might appreciate about this particular approach is that it is easy to step through and see exactly how each item is being populated. That isn't as easy with a ListView -- you'd have to add an event to catch the items being added, and then put a breakpoint in it.
And finally, I would encourage you to choose your battles carefully. This particular example is not a major design issue. If you foresee other, larger differences of opinion in the future, you might decide to start here with a smaller issue, to establish a way of resolving these kinds of conflicts with your fellow developer. Alternately, you could consider that this is not a big enough deal to fight about, and wait for something of major importance (and I doubt that you will have to wait long). Which way you choose to proceed depends upon the personalities involved.
Related
See title. That's all I have to ask. The net doesn't have many succinct answers to this question. Please keep in mind stack vs heap. Explain as you would to a complete beginner. Just looking for the "why" not the "how".
edit
Are pointers a way to get large objects out of the stack?
When passing a huge object from one piece of your program to another to be worked on like an entire class for example or something with a large amount of data like an image or video passing every single bit of data would be very inefficient. Instead you can just pass a tiny little memory address (pointer) that the receiving part of your program can then use to get to the object to be worked on.
Aside from that huge aspect, they offer a lot of flexibility but I need more than a paragraph for that.
When you get into managed code like C# or Java EVERYTHING is done with pointers/references but it's all behind the scenes and you don't have to deal with them like you would in C++ or another similar language. But it's still crucial to understand how they work.
Edit in response to:
"why would I pass a large object around if I don't need to work on
it?"
You wouldn't. However; Correct me if I'm straying from what your asking but what you'll learn if you continue into Computer Science is that a piece of your program should be as simple as possible it should only do 1 thing. Commonly known as the Single Responsibility Principle this dictates that you will have many seemingly tiny parts of your program that will all work together to accomplish the over arching goal. That means that a lot of those tiny pieces are going to need to work on the same objects, the same data and use the same tools to get the job done. Lets look at a hypothetical.
You're coding a simple image editing application.You're going to need a cropping tool, a paint brush tool, a selection tool, and a re-size tool. Each of these tools are going to need their own place in your program (a class or more likely many classes that work together) and that class will have many smaller pieces (methods/functions and other things) that work together to accomplish the goal of that class. Every single one of these classes and methods is most likely going to need to look at or modify the image data. With a pointer you can provide them with a memory address instead of making an entire copy of the image. That way when one of the classes or methods makes a change to it you don't need to worry about managing all these copies and making sure they all get the same change.
It allows you to do pass-by-reference/shared data structures, which has two big features: it saves memory and CPU overhead by not making copies, and it provides for complex communication patterns by making changes to shared data.
I have an idea for a business that requires a well designed web application. I'm not a rocket surgeon, but I'm smart enough to know that you get what you pay for and am willing to pay for talent. However, I want the development process to go as smoothly as possible and would like to know how to make that happen.
So, what information do developers need (or want) initially from the owner to avoid having to make assumptions about business (or other) requirements? Do I need to create state transition diagrams or write use cases?
Essentially, how do I take the concept in my head and package it in a way that allows the developer to do what they do best? (assuming that is creating good software. haha)
Any advice is appreciated.
Shawn
You may need to reword your question, as it is too general to get a good answer, so some vague details would be helpful.
But, the better vision you have of what you want the smoother it will be.
I find UML diagrams too confining, when you aren't going to be doing the work, as you may not come up with the best design.
So, if you start with designing out what each page should look like, as you envision it, then you can write up use cases, which are short scenarios.
So, you may write up:
A user needs to be able to log in using OpenID.
This will tell the developer one function that you want, and who you expect to do that action.
But, don't put in technologies, as you may think that a SOAP service is your best bet, but upon talking about it you may find that there is a better solution.
Use cases are good points to show what you are envisioning, and give text to your page designs.
Talk to the developers. Explain what you want and why you want it. Together you make the flow charts and whatnot. Writing requirements is part of the design process, and it's a good idea to have the developers onboard as soon as possible. Start simple and small, then grow and expand while iterating.
In talking over web services before, I have found the best starting point is drawing on a sheet of paper what you think the site will look like, and add in a few arrows from things you want clickable to the pages that should result. Keep it simple, nothing too fancy, and hopefully you and the developer can come to an understanding of what you want pretty quickly.
Use cases might be best for checking off all the points later in the project about how complete your site is; I haven't really found it to be a helpful starting point, but I'm sure others disagree. (They just seem too tedius to read when actually writing code.)
Same with state transition diagrams; they are too tedious and I think most developers will assume you made mistakes in them anyway. :) Everyone else does... Unless your project hinges very tightly on the correctness of a state machine, I wouldn't really bother.
This book contains some good advice on what constitutes a good statement of requirements from a programmers point of view. It also has the useful guideline of not trying to set the form of your requirements too early, and a substantial piece on describing the problem you are trying to solve.
I like UI mockups based on actual program/site flows e.g registering a customer or placing order. Diagrams/pictures of GUIs with structured, consistent data examples are unambiguous.
I agree that UML and use cases are only really useful if everyone speaks UML and the projects are of sufficient complexity (few are).
You may want to read up on Agile/Scrum techniques. These are becoming a sort of standard and when properly managed can save weeks of development time.
I find that words don't do a good job of communicating how a system is supposed to work. Wireframes, white-board drawings/transition diagrams, and low-fidelity prototypes are great ways to communicate a concrete idea. One example of a low-fidelity prototype is a "clickable" paper prototype that allows a user to touch "buttons" on paper to go from one drawing to another. It costs very little time (cheaper), but goes a long way to communicate an idea between two parties.
Stay away from formal documentation, UML diagrams, or class (technical documentation) diagrams that don't speak to you. This is what large, risk-averse companies move toward to be more "mature". These are also byproducts of an idea that is hashed out, and it sounds like you're in the hashing out stage.
Is it bad to be semantic purist all
the time, at work? is it not achievable all
the time ?
when i saw code of any other
person/interviewee. I know selection
of element for a purpose is most
important thing.
what i should judge person ability
from his code; from a good written,
managed, optimized css or how he
wrote class and id names?
Or both every time.
Is it bad to be semantic purist all
the time, at work? is it not
achievable all the time?
Yes. Sometimes the tools doesn't work the way that you would like, and you just have to use something that does work. It's worth a little effort to make the code more semantically correct to make maintenance more effective, but at some point you just can't defend the development cost because the gain in maintenance that it would give is a lot less.
what i should judge person ability
from his code; from a good written,
managed, optimized css or how he wrote
class and id names?
Anyone can have bad habits or incomplete knowledge in some areas. You should rather judge a person on the ability to see the difference between good and bad code when presented with it, and for showing a certain interrest in getting it right.
It depends on what you mean by "semantic purist".
Is his code so bad that you MUST refactor it first before you can do any maintenance on it or even be able to understand what the heck it does? Then it's important.
If the code is not perfect by your standards but udnerstandable, AND can be maintained, AND the person seems receptive to your hints about ways to improve it - especially if those hints are accompanied by explanation of why the improvement makes the code X% more readable/stable/maintainable, it's not THAT important what their level of "purity" is now.
If the person is willing to spend extra week polishing their code to be semantically pure at the cost of shipping late, he's a net loss by a big margin.
To give a specific example for css, if someone will add a class to EVERY element on a page just because it "should be added", bad.
If they indicate that the class needs to be added to places X, Y and Z so that jQuery selectors perform 20% better than alternative solution, VERY GOOD.
Both actually contribute to different abilities. A great abstraction design in Classes and Properties will depict his ability to analyze things where as a well writted managed optimized css expresses that he is himself/herself an organized person. The later property is also very important.
Still I will go for the first property if the css is atleast presentable.
Are you in danger of setting up a false alternative? We can either choose class and identifier names carefully or we can write working CSS? Ideally I'd prefer someone who can do both.
What do you deduce about the likely quality of a person's work if their job application has serious misspellings? Like the misspelling the name of the company they are applying to! What do you deduce about a project proposal that mis-states the objectives of the project? A person applying for a SW security job who confuses "authentication" and "authorisation".
In the interview you are trying to determine from a very small sample of information the likely way a person will perform if they come to work for you. We need to factor in many factors such as the effect of interview pressure on some folks performance, and whether they are working in their native language. I don't see any absolute standards here, and no scope for simple either-or questions such as you pose.
Of course we need them to be able to produce code that works, that's the easy bit! Quality of code, and quality of other aspects of work also do matter.
I'm working on a 10 page web site with a database back-end. There are 500+ objects in use, trying to implement the MVP pattern in ASP.Net. I'm tracing the code-execution from a single-page, my finger has been on F-11 in Visual Studio for about 40 minutes, there seems to be no end, possibly 1000+ method calls for one web page! If it was just 50 objects that would be one thing, however, code execution snakes through all these objects just like millions of ants frantically woring in their giant dirt mound house, riddled with object tunnels. Hence, a new anti-pattern is born : AntFarm.
AntFarm is also known as "OO-Madnes", "OO-Fever", OO-ADD, or simply design-pattern junkie.
This is not the first time I've seen this, nor my associates at other companies. It seems that this style is being actively propogated, or in any case is a misunderstanding of the numerous OO/DP gospels going around...
I'd like to introduce an anti-pattern to the anti-pattern: GST or "Get Stuff Done" AKA "Get Sh** done" AKA GRD (GetRDone). This pattern focused on just what it says, getting stuff done, in a simple way. I may try to outline it more in a later post, or please share your ideas on this antidote pattern.
Anyway, I'm in the midst of a great example of AntFarm anti-pattern as I write (as a bonus, there is no documentation or comments). Please share you thoughts on how this anti-pattern has become so prevelant, how we can avoid it, and how can one undo or deal with this pattern in a live system one must work with!
I think that Parnas pretty much nailed it in On the Criteria to be used in Decomposing Systems into Modules. Each module should hide a design decision, one that may change in the future. In general, a module with nothing to hide is usually just overhead. He wasn't talking about classes exactly, but I think the reasoning still applies.
If is is indeed due to over design (and it sounds like it) then here are some synonyms for you:
Gas Factory
Rube Goldberg machine
Heath Robinson contraption
But my personal name for this "trying too F#$%3n hard". My condolences.
Cheers
Adrian
Many files where one would do. Nasty. 500 objects for 10 webpages seems a crazy ratio.
Have you considered running code analysis on the solution? Might give you some interesting stats to fight back with.
Also I'd call the anti-anti-pattern KISS.
Thanks Glomek the article is for an interesting problem-space, going to the core of what is OO, i.e. how to design your objects...for success or failure, thanks for the link.
Oh yeah, the anti-pattern design could be called "Ant Hill", that's a clearer description I think. I do believe it is quite prevelant right now, and seems to be growing...I'm still wondering how we can get away from it in general, and write clearer, simpler code that gets the job done with just the minimal complexity needed.
The problem here is that your design pattern is, itself, non-OO. Start with a non-OO pattern, try to implement it as "objects", you end up with a mess.
Just because the system is written in an OOPL doesn't make the system OO.
If you consider that an ant farm is an efficient way to explore a complex problem space (the ant farm) through the use of simple agents (the ants) then this starts to look decidedly less anti-patternish.
Critiques of OOP based on the complexity of 'fitting it all in your head' always ignore that (a) its hard to fit all of anything in your head (regardless of whether its OO or not) and (b) that OO actively reduces the need to have it all in your head anyway
Another discussion (we've been having a lot of them these days!) in our work is whether data binding is a bad idea or not.
Personally, I think it is a Bad Thing™.
My reasons are thrice:
It circumvents my well architectured MVP framework - with databinding, the view communicates bi-directionally with a model. Ewww.
It promotes hooking up view controls to datafields at design time. In my experience, this leads to vital code (binding column A to Field X) being obscure and hidden away in some designer file. IMO this code should be explicit and in-your-face, so that it is easy to modify and see what is going on, without having to use a clunky designer interface.
Relating to Point #1 this direct binding makes it harder to isolate each component (view, model, controller/presenter) and unit-test.
The pros are that it is easy to set up, and you can take advantage of some nice features (validation etc) which come with the plumbing already done for you.
But for me, databinding becomes much more of a hindrance when dealing with a large data-centric application.
Any thoughts?
As we say in the UK, "It's Horses for courses"
First off all, I agree with you! But...
For enterprise level applications, then spending the extra time on the system architecture, modelling and standards will give you a robust and sustainable system.
But it will take longer to develop (or at least longer to get to an initial release) and this may not be appropriate for every system or every part of the system.
Sometimes you just need to "get it done and done quick". For internal applications, back office systems and maintenance applications that are rarely used or very dynamic (the spec's change often) then there is little justification in building the Rolls Royce solution for this. It's better to get the developer spending time on the CRITICAL part of the system.
What you have to avoid / prevent is using these "one click framework" solutions on the MISSION CRITICAL area's of the system where the big transaction rate area's and where data quality and integrity is critical. Spend quality time shaving the milliseconds off on the most heavily used area's on the system!!
Another discussion (we've been having a lot of them these days!) in our work
is whether data binding is a bad idea or not.
Personally, I think it is a Bad Thing™.
Strong opinion, but imho, you bring out all the wrong reasons.
It circumvents my well architectured MVP framework - with databinding, the view communicates bi-directionally with a model. Ewww.
I guess it depends on the implementation of the data binding.
In the early years of my programming career, I used to do a lots of VBA for MS Access programming and Access forms had indeed this direct binding to tables/fields in database.
Most of the general purpose languages/frameworks have databinding as a separate component, do not use such a direct binding and are usually considered as a easy generic dropin for a controller in MVC pattern sense.
It promotes hooking up view controls to datafields at design time. In my experience, this leads to vital code (binding column A to Field X) being obscure and hidden away in some designer file. IMO this code should be explicit and in-your-face, so that it is easy to modify and see what is going on, without having to use a clunky designer interface.
I guess you are talking about the binding in WinForms?
My experience with win forms comes from a long ago, so I might be pretty out of date here.
It sure is a convenience feature, and I would strongly argue against it, unless you are writing really simple modal context CRUD style interfaces.
Relating to Point #1 this direct binding makes it harder to isolate each component (view, model, controller/presenter) and unit-test.
Again - assuming the view (a widget in WinFoms?) is tied together with databinding awareness, you are right.
But for me, databinding becomes much more of a hindrance when dealing with a large data-centric application.
Quite contrary - if data binding is implemented as an independent component (eg. bindings in Cocoa or JFace DataBinding, or JGoodies Binding), that acts as a controller between View and a Model, taking care of all the nitty-gritty of event handling and conversion and validation, then it is just so much more easier to use, change and replace than your custom controller code doing just the same thing.
The only downside of a general purpose data binding framework is that if the binding is off and/or misconfigured, the interactions between bound pieces are just notoriously difficult to debug due to the level of abstraction inside the data binding code... So You better not make any mistakes! ;)
I've used databinding in some pretty large systems and find that it works pretty well.
Seems that I do things a bit differently from you though ...
... I don't databind to the model, instead to a dedicated view class that works as an adapter between the model's structure and what I need on screen. This includes things like providing choices for comboboxes & listviews, and so on.
... I never set up the binding using the UI. Instead, I have a single method (usually called Bind() or BindXYZ() that hooks everything up in one place.
My Model remains agnostic, knowing nothing about databinding; my Presenter sticks to the workflow coordinate it's designed for; my Views are now also simple classes (easy to test) that encapsulate my UI behavior (is button X enabled, etc) and the actual UI is relegated to a simple helper on the side.
I have had a few unshakable realizations about data binding over the last few years:
The claim that the data binding allows for the business and presentation to be designed in isolation of each other is actually really quite far from what actually goes on in reality. Usually the deficiencies in the technologies become readily apparent and then all you have done is break apart the UI from the UI-specific business and the resulting separation often becomes far more unwieldy than a all-in-one approach.
Most data binding engines (HTML / WPF / or whatever) all make assertions on the technical business model, and since the designer is not usually equipped to make said assertions, the developer ends up having to touch the view. Not only that, the view shouldn't be making assertions about the business model---if anything, it should be the other way around.
Most of the time, the view model / controller / model / view are all "coupled" and then all you have really done is "move code around" rather than just simply using code behind. With that said, I do find the most pragmatic approach is often to just use data binding sparingly with code behind and forget about MVVM/MVC esque patterns.
Developers often put view level concerns on the view model and then start to use data binding as a crutch rather than a proper approach. for example, I have seen so many view models controlling visibility of UI elements.
Admittedly, data binding is useful for "small systems". I have observed that the performance, complexity and maintainability dramatically suffer as an application grows in richness.
Memory usage techniques with data binding can often become a real hazard. WPF for example uses a LOT of trickery to avoid issues and often developers can still shoot themselves in the foot. Unless you are using something like Sencha for HTML (I think), you will find your memory foot print on your applications start to suffer even with a modest amount of data.
I have found that data binding / UI patterns in general sometimes tend to break down a little when dealing with hierarchical and situational data / presentation.
My personal outlook on data binding is that it is a tool that can be easily abused yet has some compelling uses. You can say the same for any technique, pattern, or guideline. Like anything, too much of something tends to become a problem. I tend to like to try and use the most pragmatic approach for the situation. Prefer consistency when it is pragmatic to do so, but consistently be pragmatic. In other words, you don't have to go down the path of developing for two years and only then come to the conclusion that the code base has become a grotesque smelly mammoth in a china shop full of orphan kittens.
...
#Point 1: Isn't the data binding engine the controller, if you really want to think in patterns? You just do not program it yourself, which is the whole point of using data binding in the first place.
No. DataBinding when used correctly is a Good Thing™.
No; but see #2 and #3. Make the Presenter expose the properties/well-defined sources to bind. Do not expose the Model. Nothing is circumvented.
I agree. I do not use any of the standard ASP.NET data-sources. Instead I use GenericDataSourceControl which is wired to a "select method" that returns well-defined types. The DataSource consumers in the View only knows of these Presenter-types; nothing more.
No. Relating to #1. The Presenter exposes the properties/well-defined sources to bind. These can be tested without the view for correctness (unit tests), and with the view for correctness of application (integration tests).
(My Experience is using ASP.NET WebForms, which may differ from other data-binding scenarios.)
#Timbo:
Yes and no.... but from a TDD perspective I'd like to cordon-off each controller so that I can test it in isolation. Also, say we want to run each edit via an EditCommand (so that we support Undo, for example) - for me, this rules out databinding.
#Guy:
Yes, this is exactly my POV. For me, databinding is great for very simple apps, but we don't do any of those!
I feel that in many frameworks, data binding is just an excuse to do things the easy way. It often results, as does almost any designer-generated code, in too much code which is too complicated and can't be easily tweaked. I've never come across a task I couldn't do just as well (if not better) and, in most cases, just as quickly, by data binding as by writing the code myself.
I have used databinding on large enterprise systems inconjunction with a framework. In my case it was CSLA.
It worked so well, and was extremly fast to get the view working. CSLA has lots of support for databinding and validation built in though.
If it breaks the MVP patturn, so what? if it works better and faster and is easier to manage. However, I would argue that it doesn't break the patturn at all... You can hook up databind in the presenter as it has a reference to the view and also to the model.
for example this is what you would put in your presenter and it would populate the list box or whatever control you want.
myView.list.datasource = myModel.myCollection;
Also I would like to point out the databinding shouldn't be taken as an all or nothing approch. Many times I use databinding when i have a simple and easy UI requirment to map to my object model. However, when there is special functionality needed I might put some code in the presenter to build up the view as I need it rather than using databinding.
Alan
I quite agree with you, data binding have drawbacks...
In our application, if not used carefully, it leads us sometimes to bad data consistency...
But there may be some elegant ways work with databinding with large forms?
Please give me your opinion here:
How to use a binding framework efficiently