I am trying to write wrappers library over telerik controls of MVC.
reason behind this is i can easily change third party control without change in View,Controller.
Is it good idea.
I am facing problem to hide telrik completely because, they have there own js and return objects.
Am i in correct direction?
Sounds like an abstraction to far. How many view pages are you talking about? Do you have a concrete requirement to be able to change? The odds are you will lose some of the power and just gain a lot of hassle. Probably easier to rewrite the views if is ever required. If you are that worried you probably maybe you should use a non commercial alternative? However it depends what parts you are using I only used the Grid really and we switched our site to DataTables without much issue.
I use Telerik and have never abstracted it but the rest of my architecture is flexible. I don't ever tie Telerik controls directly to a domain entity list etc. I always use a ViewModel mapped from the Domain entity using AutoMapper.
The UI in most business applications is the least significant part and is normally relatively easy to change if you haven't tightly coupled it to your Domain Model.
Related
I have an existing application which is quite large, uses a SQL Server database and LINQ to SQL built in MVC. It does what it needs to do very well, but the CMS is sadly lacking (it's difficult, complicated to use and prone to errors).
I like the look of Composite C1 to migrate this application to so that my users can get a good CMS experience.
I don't really want to center my development around C1, so I've been looking at creating an MVC application:
http://docs.composite.net/Functions/MVC
I've created a sample controller, view and then returned some static data to the view and finally posted some data to the controller. All works as a "normal" MVC application would do.
Has anyone used this concept for a real world application? The idea is that if a user want's to display one of my controls on a page they just add the control via the Composite editor. I'll also add basic pages on installation.
It's a bit of a vague question, but I'm really looking for feedback on the following:
1) How "involved" do you need to be with Composite C1 stuff? I want to just create my controllers and other classes to do my work
2) How is the performance with this approach?
3) Is there many gotcha's that you've experienced?
I have built a larger application within/on top of a Composite C1 environment, so I can say its definitely possible and the compatibility with .NET application development is actually one of the main reasons why we chose Composite in the first place.
1) How "involved" do you need to be with Composite C1 stuff? I want to just create my controllers and other classes to do my work
You won't be able to completely ignore everything Composite related when developing a full fledged application however, simply because your controls/views/controllers will run on and be rendered by Composite C1. So necessarily some of the work is done at least in part by the C1 foundation you build on, e.g. Routing, Exception Handling or Rendering.
However you can usually work with or around those features without too much trouble. It may however take some understanding of how Composite works.
2) How is the performance with this approach?
So far I cannot say that Composite would slow down the application in any significant way. It may in fact support you in tasks like Output Caching.
3) Is there many gotcha's that you've experienced?
This is a very broad question, but you generally will always have to make sure you know whether something belongs in one of your controls or would be better fit into a Composite component (page, reusable html block). If you put things into the wrong place, the easiest things will become complicated (like creating a page link) due to information being not present in the current context. But as I said, you can solve this through clever design.
Another thing to look out for is that correct source versioning is a bit harder to set up in the first place with a Composite application, because you have to figure out what is content and what is application.
So far I have made good experiences with C1 and will be using it in the future. It may take a little more time to get into it in the first place compared to a vanilla ASP.NET application, but the work that is done for you regarding CMS parts is well worth it.
I'm building a MVC4 app, I've used EF5 model first, and kept it pretty simple. This isn't going to a huge application, there will only ever be 4 or 5 people on it at once and all users will be authenticated before being able to access any part of the application, it's very simply a place order - dispatcher sees order - dispatcher compeletes order sort of application.
Basically my question is do I need to be worrying about repositories and ViewModels if the size and scope of my application is so small. Any view that is strongly typed to a domain entity is using all of the properties within that entity. I'm using TryOrUpdateModel in my controllers and have read some things saying this can cause a lot of problems, but not a lot of information on exactly what those problems can be. I don't want to use an incredibly complicated pattern for a very simple app.
Hopefully I've given enough detail, if anyone wants to see my code just ask, I'm really at a roadblock here though, and could really use some advice from the community. Thanks so much!
ViewModels: Yes
I only see bad points when passing an EF Entities directly to a view:
You need to do manual whitelisting or blacklisting to prevent over-posting and mass assignment
It becomes very easy to accidentally lazy load extra data from your view, resulting in select N+1 problems
In my personal opinion, a model should closely resembly the information displayed on the view and in most cases (except for basic CRUD stuff), a view contains information from more than one Entity
Repositories: No
The Entity Framework DbContext already is an implementation of the Repository and Unit of Work patterns. If you want everything to be testable, just test against a separate database. If you want to make things loosely coupled, there are ways to do that with EF without using repositories too. To be honest, I really don't understand the popularity of custom repositories.
In my experience, the requirements on a software solution tend to evolve over time well beyond the initial requirement set.
By following architectural best practices now, you will be much better able to accommodate changes to the solution over its entire lifetime.
The Respository pattern and ViewModels are both powerful, and not very difficult or time consuming to implement. I would suggest using them even for small projects.
Yes, you still want to use a repository and view models. Both of these tools allow you to place code in one place instead of all over the place and will save you time. More than likely, it will save you copy paste errors too.
Moreover, having these tools in place will allow you to make expansions to the system easier in the future, instead of having to pour through all of the code which will have poor readability.
Separating your concerns will lead to less code overall, a more efficient system, and smaller controllers / code sections. View models and a repository are not heavily intrusive to implement. It is not like you are going to implement a controller factory or dependency injection.
A junior developer on my team just created a screen using an MVC Helper called WebGrid.
My first reaction was a classic NO! to anything that sounded like Grid / bound tech.
As he demo'd the functionality, it wasn't bad, though it did use
?sort=Title
type of syntax which bothers me generally. He also showed me many examples of posts regarding use on forums like Stack. One such warned against their use, but was categorical and gave no clarification. I would like to know if users have any positive or negative experiences with the WebGrid control.
Would you recommend for or against as "best practice"?
I don't think you're going to get a definitive answer to this question, but I think it's a good question and deserves an answer (others may vote to close it, just as a heads-up). But this is my personal take, FWIW.
One of the benefits, to me, of MVC (vs. Web Forms) is that it provides almost full control over the rendered HTML. With Web Forms, .NET did its own crazy thing to get the front end bound to code behind, and this was magnified with using web controls.
Generally speaking, the same could be said about using controls like this in MVC -- they often limit the control one has over the rendered HTML.
Another argument is that they typically limit what you can do via client-side code (or how easy you can do it). This may be a side effect of not having full control over the HTML.
I would take a look at the HTML it produces -- you may quickly see enough reasons there not to use it (or, to use it).
Of course, the other argument is that third party controls often try to do too much, or do things differently than you'd like (like passing the sort through a query string, as you mentioned).
I am planning to build a web application using ASP MVC3 that runs on Azure with a SQL Azure back end. I would like to use the Microsoft stack and have no plans to ever change to another stack. I am looking into the use of WCF and WF but that would be in the future.
I looked at the traditional and Code First approach to using Entity Framework but I can't see if there is any advantage in using one or the other approach. Sure they each have advantages but for me I don't care if my classes do inherit from EF classes. All I want is to find the most efficient solution.
Can anyone out there give me some advice as to which approach might be the best.
thanks very much
Richard
This is really more of an opinion gathering question and probably belongs more to the Programmers site of StackExchange, but I'll take a stab:
I am definitely a traditional approach kind-of-a-guy. To me, data is key. It is most important. Various objects, layers, applications, services come, go and evolve. But data lingers on. Which is why I design my databases first. In my experiences, data has always been king.
I'd go with Code First approach.
This great blog post by Scott Guthrie explains its advantages.
Code first for me also. If you suddenly started to hate Entity Framework and wanted to switch to NHibernate you will have a lot less work on your hands.
Also, there is a cleaner separation of concerns by totally isolating your domain layer from your data access layer.
I am not 100% sure it still applies, but I think the code generation, partial class malarky of entity framework can cause problems when testing.
Did I mention code first is a lot less hassle.
Code First is an "Architecturally correct" approach, but reality tends to differ on these things when you have to consider effort, value, and speed of developement.
Using the "Model First" approach is much faster and easier to maintain. Database changes propagate with a simple right click "Regen from database", you don't get strange errors creeping into your code when you forget to change a property name or type.
Having said that you can have a bit of both with the the new POCO support in EF4. You can remove the dependencies on base classes while at the same time use the modelling tools:
A lot of good links in this thread:
Entity Framework 4 / POCO - Where to start?
I'm looking for recommendations for a spreadsheet-like input facility to sit in an ASP MVC environment.
The client currently has a large number of very complex interlinked shared spreadsheets (which they are effectively running 90% of their core business from) for collecting and processing information. They wish to move this to a web application and require ASP MVC. They realise that they will not be able to display as much information on screen as they do currently with their spreadsheets, so a 40 x 60 grid should suffice in most cases. Of this they'll be a limited number of cells for data entry that will immediately update other cells in the grid using various spreadsheet-like formula. The grid must be AJAX enabled.
The quality of the user-interface is of primary concern here. As inevitably there will be a certain amount of resistance to move to database/web (and this project is a pilot anyway) the system must be as slick as possible. Almost as important is ease of implementation - the final system will be quite large so the quicker it is possible to configure the grid the better.
Either Open Source or commercial would be fine. HTML/Javascript, Silverlight and Flex implementations can all be considered.
I initially asked a similar question a year ago (it's taken that long for the client to agree the project) but I'm sure options have changed since then and our environment is now better defined.
I think Grapecity Spread will fit the bill , it can be easily built with MVC pattern and now it also supports the Razor View Engine .There is already a blog which details how to use Grapecity Spread with MVC , you can go through this here
http://www.gcpowertools.info/2011/12/using-grapecity-spread-for-net-with-mvc.html
Microsoft Silverlight. It is almost certainly your best bet for a rich line of business application with web deployment. It will allow you to utilise a consistent code base across your back-end and front-end component.
Whilst a number of commercial datagrid packages exist (Telerik, etc), I'd suggest using the default Datagrid component that is available, and understanding fully the databinding and templating options available.
Check out YUI's datatable, maybe what you need
http://developer.yahoo.com/yui/examples/datatable/dt_cellediting.html
I have used it and its great, very developer friendly and supports pagination.
When asked for a multi-line editable grid, I've done it two ways.
Dropped a SL control onto the page. This was incredibly easy.
A lot of javascript. Double-clicking a row made a row editable with several textboxes to span the gap. I don't think is what you're looking for, though.
For something quick and easy have a look at JqGrid demos to see if it can do what you want
http://www.trirand.com/blog/jqgrid/jqgrid.html
JQuery is already in MVC and being javascript it will work without plugins for the browser. However it may not be powerful enough for what you want in which case you going to need to look at Silver light etc. Could the project not be approached in a more web friendly manor?