Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm coming from recenelty working on ASP.NET WebForms, and other Web Development frameworks .
Lately i wanted to get into the ASP.NET MVC. I read a Pro book and have some missing link that i can't understand .
How can you use MVC when many cases doesn't fit it exactly . What do i mean ?
In WebForms for example, you want to build a page, that has all kind of elements, that has nothing to do for your 'real' model. For example, just use a page to show a small chat, or some kind of ad, and some more kind of controllers that doesn't represent a data in your DB.
In MVC as i understand, the whole concept is to build pages with specific relation to their Model, and then it everything flows from there .
So for a store (most of MVC projects examples) it fits greats, some product, cart ...
My question is, how can you use MVC when you have all kind of pages that doesn't require a specific model use ? does that lose the whole point of using ASP.NET MVC ?
For most of what you're talking about there's child actions (MVC 5 and previous) or view components (MVC 6). For example, you can create a child action/view component that renders the chat control, and then you merely call this in your view/layout, and your view still just worries about the actual model its dealing with.
You can also utilize partials to render portions of mostly static HTML. If that chat control, for example, was just HTML/JavaScript, you could just include it in a partial and then call that in your view/layout. The main difference between a child action/view component and partial in this context is just whether or not you need to get and pass some stuff to the view server-side first. In effect, if your control needs a model of it's own, use a child action/view component, other wise, a partial can suffice.
You can also extend HtmlHelper to add "controls". This is useful where there's some server-side processing that needs to be done, but it doesn't require things like hitting a database, that should be handled by your controller. Think of it has kind of a midway between a child action/view component and a partial.
Finally, although the confusion is understandable, due to the tight integration between Entity Framework and MVC, the two are actually totally interchangeable. In other words your view's "model", doesn't need to be involved with a database at all. The model is just a class instance, and that can come from anywhere, be it a database, a web service, or just statically instantiated in the action.
Related
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 months ago.
Improve this question
How do I access the View Model from inside a Layout? I can only think to use ViewBag and ViewData, which seems to contradict the MVC pattern.
I would like to do this because I don't like the way .NET MVC is designed when it comes to pushing data to layouts and non-layout views.
Once can pass a model to the "content root view" (i.e Return View(myModel)), but cannot do the same when it comes to the layout. For the layout, one is forced to use ViewBag or ViewData.
I like the idea of having a "data tree" that perfectly corresponds to my "view tree", and have each view pick its own values from the data, and pass-on the right node to its child views at the moment of including them. I like that because it avoids key name conflicts that you might encounter when using a single dictionary-like collection like ViewBag or ViewData for a tree of views unaware of one another.
But that fact that .NET MVC doesn't allow passing models to the layout is forcing the use of two différent methods to do the same thing, i.e using ViewBag or ViewData for the layout, and a "data tree" model for the "content root view", which doesn't seem right to me.
I would have liked to have a single entry point for pushing data to my views, and that would have been the layout itself, not the "content root view".
So based on that, my idea was to stop using layouts completely and, instead, have a root view that would be used as a layout, which would include a tree of partials views, meaning I would never call #RenderBody(), but rather call Html.Partial() instead.
However, this is moving away from how .NET MVC is supposed to be used, and I know by experience it can lead to problems when not using a technology how it's supposed to be. So here is my dilemma, I don't know if I should just code it how I want it to be coded and take the risk of encountering problems further down the road, or just use .NET MVC the way I'm supposed to and be stuck with this hybrid way of passing data to my views.
I would be interested to see a specific code example of the problem you're facing, for context, if you have one?
Going on what you've said, you are right to be suspicious that you've been forced into using the ViewBag as it's not really something we should be using if we can help it. Obviously it's there and can be a good "get out of jail free card", but sticking to view models is certainly better.
Have you considered defining and using sections in your layout/view? They essentially work like a named version of RenderBody.
For example, in your Layout you might have:
#RenderSection("SideBar", required: false)
This can be accessed from your view, like this:
#model your.namespace.viewmodel
... some view cshtml ...
#section SideBar {
<h4>Related content for #Model.Name</h4>
...
}
Check out this overview of sections, it includes more in depth examples and also how to define default section content on the occasions you don't want to pass anything.
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 5 years ago.
Improve this question
MVC 6 Introduced View components and said it is much stronger and flexible than partial views. Are view components meant to replace partial views? What is the difference and what kinds of situations call for each implementation?
According to this link- https://docs.asp.net/en/latest/mvc/views/view-components
New to ASP.NET MVC 6, view components (VCs) are similar to partial views, but they are much more powerful. VCs include the same separation-of-concerns and testability benefits found between a controller and view. You can think of a VC as a mini-controller—it’s responsible for rendering a chunk rather than a whole response.
So it just a enhancement of partial view and another difference is when you use partial view you still have dependency on controller while in View Component you don't need a controller. So there is a separation of concern.
There is a detail post for ASP.NET View Components.
http://www.tugberkugurlu.com/archive/exciting-things-about-asp-net-vnext-series-mvc-view-components
An example where you might want to use a ViewComponent as opposed to a PartialView:
You need to write a bunch of business logic where for example you might need to contact a 3rd party web service and get the data and do something with it and then display this information.
For the above scenario, sure you could write C# code in the partial view itself, but its ugly and also you want the code to be testable. So this is where a view component can be useful, i.e you can write all your business logic within a view component and return a view (this is of type ViewViewComponentResult).
View components are NOT the same as child actions.
ViewComponents are also used when you need a partial view, that requires a model to be called in _Layout. To avoid writing C# code to create the model in the Layout, it's best to use a ViewComponent that can make use of the Services configured for the application, same as controllers, through dependency injection.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We have an ASP.NET web-application which has become difficult to maintain, and I'm looking for ideas on how to redesign it. It's an employee administration system which can be highly customized for each of our customers. Let me explain how it works now:
On the default page we have a menu where a user can select a task, such as Create Employee or View Timesheet. I'll use Create Employee as an example.
When a user selects Create Employee from the menu, an ASPX page is loaded which contains a dynamically loaded usercontrol for the selected menuitem, e.g. for Create Employee this would be AddEmployee.ascx
If the user clicks Save on the control, it navigates to the default page.
Some menuitems involve multiple steps, so if the user clicks Next on a multi-step flow then it will navigate to the next page in the flow, and so on until it reaches the final step, where clicking Save navigates to the default page.
Some customers may require an extra step in the Create Employee flow (e.g. SecurityClearance.ascx) but others may not.
Different customers may use the same ASCX usercontrol, so in the AddEmployee.OnInit we can customize the fields for that customer, i.e. making certain fields hidden or readonly or mandatory.
The following things are customizable per customer:
Menu items
Steps in each flow (ascx control names)
Hidden fields in each ascx
Mandatory fields in each ascx
Rules relating to each ascx, which allows certain logic to be used in the code for that customer
The customizations are held in a huge XML file per customer, which could be 7500 lines long.
Is there any framework or rules-engine that we could use to customize our application in this way? How do other applications manage customizations per customer?
If your regular data is held in a database I'm not entirely sure why you'd want to have all of that customer specific information in an xml file. Move it into the database.
Next, there are many different kinds of rules engines out there. Considering you're using asp.net you might want to look at Windows Workflow for at least some of this. You might read the following: http://karlreinsch.com/2010/02/05/microsoft-rule-engines/
A long time ago I used a product called Haley Rules to drive a c# web app. It controlled everything from the screens that were available right down to the fields that appeared and whether they were required or not. It took awhile to get the team on board with how it worked, but once that happened bringing on a new client was extremely simple. Haley was since gobbled up by Oracle, but was probably the absolute best one out there.
Others you might be interested in are NxBRE and even nCalc. NxBRE is an actual rules engine which is a port of one built for java. nCalc on the other hand isn't a rules engine per se. However, if you can express your logic in simple boolean statements then it is extremely fast. I'm currently using this to drive page flow in one of our applications.
Some commercial ones include: FlexRule, iLog
Your existing rule engine tool supports your web application, which means it meets your needs already. You can use other "Rule Engine" like MS work flow, but IMO it can also end with a hard to maitain situation.
Let's say there is registration portal. It collects general user infomation and save them into database. Simple. we build one protal for one client with several ASCXs and Rules.Then for another client,we add more rules and more controls to these ASCXs. Working in this way, sooner or later we will reach the final straw client. At that time the code base is hard to maitain and devs lost themselves in lots of rules. It is what happened to me.
So to me, it is not about which Rule engine to use.
Then How?
I have raised a question, and one of the answer makes sense to me( thought not a picked answer). In this answer, the guy mentioned what kind of company you are. In your question it is more like which department you are or do you want to seperate your dev teams.
If you are in a archetect teams, build a framework with a rule engine. Create a basic registraion portal as a sample portal.Make DAO,BO decoupled with UI (Seperate layers).
If you are in a customise teams, create customised user control (dont reuse these user control in basic version). What you will recreate is just UI, you can still use DAO,BO as they are not defined in user control, they are at other layers. In this way you get the freedom to define your client specified rules without worring about contaminating other clients rules or introducing new bugs to other client's registrations.
Just realise it is not like an answer to your question. Anyway it is my thoughts after limited xp of working on a engine rule based ,multi-clients web application.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I am undergoing training in asp.net and the topics which are being taught there these days are repeater and datalist control. I want to know that whether these things are used frequently in the companies. The other thing i want to know is that what are the topics which i should learn in depth so as to get a job. I don't want to go through out dated topics.
I am not aware of what's most demanding in asp.net job sector. Please guide me through.
yes, they are still in use. However, if you are new to Asp.net you might put more effor into learning ASP.NET MVC instead of Webforms.
MVC is a more modern approach with clean separation of concerns. Also you do not get the viewstate / abstraction that webforms has. Find out more here: http://www.asp.net/mvc
However, a lot of sites are still using the webforms approach and they are doing fine. Invest your time in the controls, in Linq and entity framework,
Data GridView, User Data Validation, and learn some basics as like Binding data, xml parser etc.
yes
talking about Asp.net all the server controls are used and will be used.. however Asp.net in itself isnt very good for learning website making as it abstracts away the underlying beautiful http request/response architecture of the web.
so if you are learning asp.net lay a great stress on ViewState that would also help you ultimately build the basics.
With it caching and update panel for ajax are also important. if possible use jquerys ajax that would tell you a lot about the AJAX thing and also would save your time.(i remember just bumping my head on update panel for hours trying to figure out what is going wrong).
then there are features in the c# language itself like linq which are very helpful with connecting to any sort of database on which you should lay stress
Every control group in asp framework is important.It depends upon the requirement of your application.To become good developer
1.)Clear all basics related with framework.
2.)You must know about all controls.
3.)You must know how you play with data.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
As I understand it, just URL re-writing is not the only thing one needs to do for making a website SEO friendly. You also needs to maximize the use of div (instead of tables), reduce javascripts, flashes and have a clean HTML.
I need to know how can this be achieved when one used a ASP.Net control. ASP.Net send loads of stuff to the screen which in technologies like PHP can be delivered using much cleaner code.
Can anybody tell me is there a way to force ASP.Net to render cleaner code and work with divs instead of table when one used datagridview.
Also I would appreciate if one can post the suggestions for making a existing website SEO friendly which was coded in ASP.Net C# 2.0
Making your site's pages "SEO friendly" is really about ensuring that search engines (Google), can understand the content on the on the pages. Using "semantic" html markup can go a long way to help the search engines.
ASP.NET doesn't so much make it hard to do semantic markup as it does make it easy NOT to.
Wrapping a sub-heading in an <h2> tag and styling the <h2> helps the search engine understand that a particular string of text has more weight than other text on the page. ASP.NET makes in easy to fall into the trap of just using a Label server control and applying styling to it to make it look like a heading.
GridView data controls render tables. If you repeating data would be better understood with more semantic markup, consider using a Repeater control or a Listview control if you need to support paging etc.
Step 1 to SEO optimization is understanding semantic markup. Then you can find the appropriate ASP.NET controls to achieve your optimized SEO output.
Server controls have been the main selling point for ASP.NET WebForms. It has allowed developers to quickly put up pages without thinking of HTTP, HTML, CSS, JavaScript, SEO or anything. Exactly this kind of knowledge you will need to consistently create quality markup that is SEO-friendly.
If you absolutely wish to stay with WebForms, you need to look at what output the controls you use render. If you don't like it then you may have to redefine their rendering algorithms or better create your own controls.
Also get some url rewriting module (or use the one included in .NET 3.5 SP1 - the one used by ASP.NET MVC framework) and define good-looking self-describing urls for your existing pages. Also take advantage of header tags (H1...H6), search engines look at them to see what the page says it is about.
I wouldn't worry about divs vs. tables and validation, this is not clear of how relevant this is for the SEO, there are too many widely different opinions on these matters with proofs to support each point of view. What does matter, is the content. As they say, content is the king.
What I would pay attention to is the view state that ASP.NET injects into pages. It is widely known that the close to the beginning of the page the content is, the better for search engines. ASP.NET steals the beginning of a page by putting there an often huge block of serialized view state (under circumstances can reach megabytes). Try to turn off view state for your pages if you can (if your server logic can be adapted to stateless operation). This will be a very important step.