So, I want to display some rules concatenated with AND or OR, and I want to add color to AND or OR like red, green etc.
Fruit = Apple AND Market = SuperMarket1
So how should I do this? I have following thoughts:
To control the css by adding the css properties in repository or service class which handles the data access, which works but violates MVC design pattern.
To manipulate the data in the View using something like the Helper class, but the problem is the helper class has to parse the string to find the AND and it is possible that if AND is part of the rule. Even it is in rare case but it is still possible that if any rule contains the keyword and displays it incorrectly.
Any idea? Thanks in advance!
Just conditionally set a span with appropriately styled class on the element you want to color in the View. You can set helpers to do this and that, but often times people get so out of hand with helpers that they needlessly complicate the app....which is the opposite of the aim of MVC. Yes, it might violate the "strict" rules that MVC is supposed to follow. But step back and think about it.....is your environment REALLY big enough that you have to 100% strictly separate a minute amount of code and the presentation layer? Really? I've worked for Fortune 500's who don't stress that much.
The thing about MVC is that you can analyze it to death. It's great help to those of us who are building complex apps. But, there's an exception to EVERTHING. If you stress about these exceptions, you're not going to get anything done. Loosen the tie, man.
Related
I've wondered this in many different situations, so here I come, looking for the experts knowledge.
Let's say I have to model something that requires a collection. A simple example: an application that stores famous quotes along with their author and a set of tags or keywords. The user should be able to enter a tag or keyword and get matching quotes for it.
My question is: do I really need a class that contains my collection of quotes? Something like this:
Or would this also be correct?
I'm asking this in the more abstract way possible (after all, UML should never depend on the implementation).
I've always thought the second example (just 1 class) was incorrect, but now I'm thinking that maybe the user can press a button on some interface and that button executes some code that gets a quote stored somewhere, and the second example would also be correct?
Basically, should I always have a collection stored somewhere, even if the storing class does nothing else but just store the collection (and provide the methods to access it)?
I definitelly prefer only one class, if there is no strong reason to have another container class (especially on abstract conceptual level). Then I add the collection methods as static functions. A separate container class would only bring more complexity, more dependencies and doubts like yours. :) Doubts often indicate the lack of a real need. When you really need something, you know it.
Here an example with some explanations. I find it simple, clear, elegant and abstract, meaning non-restrictive, easy to transform to any implementation you like:
When it comes to relationships of this class to other class, then you actially have your collection, without introducing new class. This diagram shows two examples. "Other class" actually sees a collection "quotes" which is ordered, like Vector. "One more class" also has a collection of Quotes with different characteristics.
Later on implementation level you can implement it directly like this or eventually adding a Factory or Container class, according to concrete, implemention resctrictions and special reqs.
Most MVC tutorials I've been reading seem to create 4 View objects for each Model. For example, if my Model is "Foo", there seem to be 4 .cshtml files: Foo/Create, Foo/Delete, Foo/Details, and Foo/Edit. Using the VisualStudio "scaffolding" helper does this as well.
Is this really considered MVC best-practice? It just feels wrong to have 4 classes that are 80-90% identical to each other. When I add a new field to Foo, I need to edit all 4 .cshtml files. This sort of dual-maintenance (quad-maintenance?) just makes my OO skin crawl.
Please tell me: is there an expected/accepted best-practice which handles this differently? Or, if this really IS accepted best-practice, tell me why the quad-maintance shouldn't make me squirm.
I'm a reasonably skilled veteran of ASP.NET / c# / OO Design, but pretty new to MVC; so apologies if this is a noob question. Thanks in advance for your help!
Edit: thanks for all the replies! I marked the most thorough one as the answer, but upvoted all that were helpful.
You'll probably need between two and four different views:
List (for viewing many things)
View (for viewing a single thing. Might not be necessary, if it's OK to use Edit as View, or if List has room to show all properties)
Create
Edit (can be the same as create, if you code cleverly)
Thus, if your model doesn't have too many properties to show them all in a table, and if you're OK with not having a static, non-editable view for just examining, you can get well away with just List and Edit, and scrap the other two.
However, this doesn't solve your problem of double (or triple) maintenance if you update your model. There's other magic for that ;)
In ASP.NET MVC 3, there are extensions on HtmlHelper that let you do Html.DisplayForModel() and Html.EditorForModel(). These use predefined templates to nest themselves into your object and draw up display/edit fields for all public properites. If you pass DisplayForModel an IEnumerable<Foo>, it will create a table with column headers that are the property names of Foo (using the DisplayName attribute information if you supplied it) and where each row represent one Foo instance. If you give EditorForModel a Foo, it will create a <label> and an <input> for each public property on Foo.
All of the templates used by these powerful extension methods can be replaced by you, if you're not happy with the defaults. This can be done either on the level of Foo, in which case you'd be back in your double-maintenance scenario, or on lower levels (such as string or DateTime) to affect all editor/display fields generated with the templates.
For more information on exactly how this works, google "ASP.NET MVC 3 editor templates" and read a couple of tutorials. They'll explain the details much better than I could.
The views that ASP.NET MVC create for you don't necessarily need to be the views that you use in production. I found those just to be handy while developing quick prototypes or to test the database CRUD operations. Feel free to create whatever view(s) you would like to handle the operations.
I would generally just have 1 or 2 views to handle the basic operations and not use the built in views that are generated. For example, 1 view for adding, editing, or details and 1 view to show a list of objects.
It all depends on your application.
If you have a single item, you don't need a List view. If you can't edit it, then you don't need an edit view. Create and Edit can often be the same view, unless there are special things you need to do in one, but not the other.
In other words, use as many views as you need. There's no hard and fast rule here. The scaffolding is just there to help you on your way. Many kinds of apps will work just fine using the scaffolding, and won't require advanced HTML or Javascript.
Why would you want multiple views? Well, let's take the display and edit functions. You could create one view, in which you use if statements to determine the edit mode of the view, however this will complicated the view logic and views should be as simple as possible.
The reason to create seperate views is that its easier to maintain than one gigantic view with tons of conditional logic in it.
You can use exactly the same view when you are performing [HttpGet]. Given that you pass a proper ViewModel to this view, it will populate with appropriate data every time whether you are loading create, update, or delete Action.
The problem becomes apparent when you try to post that data to a specific Action.
Naturally View should have only one form, which will be used for posting data. When you declare this form, you specify which exactly Action to use for Post.
Having 3 different Submit buttons in that form will not make a difference since all of them will post the same form to the same Action.
You could do some javascript tweaking on OnClick event for these buttons to change Action to which data is posted, but this definitively would not be best practice.
Buttom line: having 4 different views for each of the CRUD actions is the best practice for MVC.
I tend to create the following for an object's CRUD ops:
index
_form (partial)
new
update
delete
view
As the same form is shared between new and update, there is very little difference between the two. It really depends on how much you want the variation to be, honestly.
As for delete, this is optional. I like to have a view in case javascript is disabled.
edit:
You mention view models and the guy above posted a long, convoluted (no offense) VM code sample.
Personally, I hate classes written to basically mirror domain objects and are only used to "move" data. I hate VMs. I hate DTOs. I hate everything that makes me have to write more code than is necessary.
I guess I've drank the coolaid of other frameworks (rails, sinatra, node.js) to the point where I can't stomach the idea of tossing DRY to the wind.
I personally say skip um.
Edit2 I forgot list..
I've inherited a asp.net project and I'm finding that the code behind pages contain a lot of business logic.
I've decided that in most cases it's better to leave the working code in place than try and do a massive refactoring. However there are pages that perform functionality that could be re-used in command line utilities for batch processing. I'd like to focus my energies on these pages, refactoring out the business logic and referencing that in other utilities.
I am currently looking to refactor this particular page which has 6200 lines of code in the code behind. What I'm finding is it's very tedious work trying to locate the dependencies between the code behind and the page specific objects.
I'm wondering if anybody knows of a tool, a VS feature, or a method that would allow me to systematically locate and attack these dependencies? Something that will allow me to identify any area of the code that references ViewState, a textbox, panel, drop downlist, etc..., so I can move these references to method parameters and ultimately move this functionality out of the page class.
I would begin by examining any method that doesn't follow the Single Responsibility Principle and break them down so that they do. Once that's done you should have a handle on what the code does and you should be able to group the code more easily and move it into dedicated classes for those groups creating the necessary objects to use as you go. I find ReSharper is a very useful tool to help do all this. Ultimately you will always need to have a solid grasp of the fundamentals within the code before you can successfully refactor.
We've all been there at some point and you have my deepest sympathy but your willingness to attempt it at all means you're already heading in the right direction. Good Luck!
Wow first of all sorry to here that. Anyone who would put 6000 lines of code in code behind deserve to be smacked :)
Now I have done this kind of refactoring before. I would approach this in few steps:
(1) Create Logical Regions #Region and #EndRegion
Like - Save Methods , Load Methods or
(2) See if you can create physical business objects based on these regions in your business
layer
(3) Once you are done just refer all your code to appropriate class.
I understand you want some tool to make this all go away but I am afraid by doing this you will dig the hole dipper. Understanding the code and moving it method by method will give you better understanding.
One way I can immediately think is Compile then into Assemblies and Analyze the assembly using NDepend
http://www.ndepend.com/Features.aspx#DependencyCycle
(source: ndepend.com)
I was watching a tutorial on Rails and was very impressed that you could so easily create an editing system for a class just by defining it.
Can this be done in ASP.NET?
I know there are ORMs out there, but do they come with an editing system?
To explain what I mean by an editing system, consider a class for defining people
class Person
{
string First_Name;
string Last_Name
}
And then perhaps with one bold stroke something like this:
CreateEditAbleClass(Person)
You would get the functionality below in a browser:
http://www.yart.com.au/images/orm_editor.jpg
And this functionality would extend to all the UML definitions – inheritance, association, aggregation etc. In addition, there would be a simple way of adding customisable validation and so forth.
I currently use DataGrids and a lot of manual coding to achieve these results.
You can do it with reflection. Using reflection, you can enumerate over the members of a class, and therefore create a form to edit the members.
Creating the code for rendering the web form based on the members of the class is a bit more code then I'm willing to type out here, but if you look into reflection you should be able to come up with your own solution in a couple hours.
Sure. This is off the top of my head, but I believe you could connect your class to an ObjectDataSource component which would in turn connect to a DetailsView control. So it's a hair more work, but it would be pretty trivial to have a method that created the needed items on the fly and bound them together.
This is called "Scaffolding".
It really depends on what you are using for your data layer or ORM. Entityspaces, for example, comes with a scaffolding generator.
Absolutely! Scaffolding in Ruby is known as Dynamic Data in ASP.NET. Scott Hanselman speaks to Dynamic Data here.
There's a screen cast from Scott Hunter that shows it off here. It's of note that it's pretty new (still in beta).
You can for simple sites/purposes but it quickly breaks down when you want to do something more complex. Like what happens if you don't want certain fields to be visible, what happens if you have a relationship to a subset of a certain class etc.
Having been down this path before I'm guessing you came at the issue by realizing that:
You spend alot of time creating similar forms/lists etc for similar entities.
You want to minimize this time and are considering if your forms can be automatically generated.
Basically, if you want it to be done automatically then you'll end up creating an overcomplicated system that does half of what you want and actually takes longer to implement.
If however, you want to drastically cut the amount of time doing and maintaining writing repetitive gui code then then I suggest using a declarative style form builder and table builder (like the form builder in ROR).
This lets you quickly create forms/tables without repeating yourself any more than necessary and also gives you the flexibility that you need for complex scenarios.
I keep hearing about the DRY Principle and how it is so important in ASP.NET MVC, but when I do research on Google I don't seem to quite understand exactly how it applies to MVC.
From what I've read its not really the copy & paste code smell, which I thought it was, but it is more than that.
Can any of you give some insight into how I might use the DRY Principle in my ASP.NET MVC application?
DRY just means "Don't Repeat Yourself". Make sure that when you write code, you only write it one time. If you find yourself writing similar functionality in all of your Controller classes, make a base controller class that has the functionality and then inherit from it, or move the functionality into another class and call it from there instead of repeating it in all the controllers.
use filter attributes to manage aspects (authentication, navigation, breadcrumbs, etc)
use a layer supertype controller (apply common controller-level filters to it, see mvccontrib for an example)
write custom actionresults (like in mvccontrib - for example we made one called logoutresult that just does a FormsAuthentication.Logout()
use a convention for view names
most importantly - keep you controller actions dumb, look for reuse opportunities in services
Don't Repeat Yourself. It can apply to many different aspects of programming. The most basic level of this is prevent code smell. I haven't used ASP.NET so I can't get specific to it and MVC's.
In C++ Templating prevets multiple copies of the same function.
In C void * pointers can be used in a similar fashion, but with great care.
Inheriting from another function allows function allows other functions to use the same code base without having to copy the code.
Normalizing data in a database minimizes redundant data. Also adhereing to the DRY principle.
When you go over a "thought" in a project. Ask yourself.
Have I already wrote this code?
Will this code be useful elsewhere.
Can I save coding by building off of a previous class/function.
DRY is not specific to any one technology. Just make sure you look at your classes from a functionality standpoint (not even from a copy/paste coder view) and see where the duplication occurs. This process will probably not happen in one sitting, and you will only notice duplication after reviewing your code several months later when adding a new feature. If you have unit tests, you should have no fear in removing that duplication.
One advantage of MVC as related to not repeating yourself is that your controller can do tasks common to all pages in the one class. For example, validating against certain types of malicious requests or validating authentication can be centralized.
DRY should not only be applied to code, but to information in general. Are you repeating things in your build system? Do you have data which should be moved to a common configuration file, etc.
Well, the most common example that I can give about DRY and UI is using things like MasterPages and UserControls.
MasterPages ensure that you have written all the static HTML only once.
UserControls ensure reusability of code. Example, you will have a lot of forms doing basic stuff like CRUD. Now, ideally we want all users to see different pages for Create and Update though the forms fields in both will almost be the same. What we can do is combine all the common controls and put them into a control that can be reused over both the pages. This ensures that we are never retyping (or copy-pasting) the same code.
DRY is especially important in MVC because of the increase in the sheer number of files to accomplish the same task.
There seems to be a misconception that everything in a domain model has to be copied up as a special view model. You can have domain models be domain models but view models be something that know nothing of domain specifics and be more generic. For example:
Domain Model classes: Account, Asset, PurchaseOrder
View Model: List, Table, Tuple, SearchFormBackingModel:Checked options, Outputoptions, etc. The view itself might be much more view implementation specific.
The Tuple/Dictonary/Map might map to Account, Asset and PurchaseOrder single instances but a Table might be useful for a collection of them etc. You still have MVC but you have session data, not ready for transaction yet in a view model without necessarily having it violate the rules of your domain model which is where the rules should go. They will be less anemic and anti-pattern that way. You can pass these rules up front and use them there or just in back or both depending on how the system reads from clients etc.