I need some suggestions on how to resolve the issue I am having. I have tried several different options but hit limitation after limitation. Here is a brief overview of what is going on...
We have 40 tables that hold configuration data that needed to implement CRUD operations. We must use Telerik MVC Grid and preferably the INLINE editing. We must manage the original state and the changed properties on a single object. That object will later be serialized into the database for later approval.
Instead of making 40 models, 40 views, 120 crud methods(no delete), that will all closely share the same code except the field names. I am trying to create a way to make this generic enough where we can have 40 models (maybe?), 1 view, 3 crud methods.
I am running into limitation in various areas:
WCF doesn't support generics
Telerik grid doesn't support dynamic types
WCF doesn't keep methods and private properties intact
We are using MEF also, so this is a plugin, inside of a plugin.. i know..
Adding methods to the WCF layer is not permitted...
My Idea?
I thought I would try creating a class to hold the state, well call it ManagedState. I originally wanted the table models to inherit from it and I had it linked to track changes but this was not working.
I also have now tried using the ManagedState class separately from the configuration class
and using that strictly to pass back and forth through our WCF service. Then try using that data to create the original type and hydrate it.
Really there is so much that has gone into this I am flustered. I have no particular code to share as this is an overall question of how I would implement it as I am hitting brick walls all over. I can post code in future if I get a good response to attempt another method to implement.
I see this question had a lot of views so I figured I would respond to answer my question.
I pretty much used T4 templates to generate a TelerikGrid HTMLHelper. The Telerik grid code was generated for each type unfortunately but all I had to do was call the helper and pass my type in and it used a case statement to return the correct grid.
Related
I've just finished creating a custom surface controller that sends out emails after a user has filled in details of a contact form.
However I'm trying to now store these records in a custom table but I'm not sure what available methods I have of doing this? In previous versions of Umbraco ie. < 4.8 I'd create Linq 2 Sql classes and then save my records using the DataContext object.
Now that Umbraco 6 has moved to MVC I'm a little unsure how I should proceed. I've been looking into using Entity Framework to add my custom records but now I've just seen this article and I wonder if there's another simpler way of adding these new records to my database?
Is anyone able to point me in the right direction here? What is the optimal way of adding records to custom tables in umbraco 6?
Thanks!
There are two answers to this question:
Use a framework/solution like EF;
Use Contour
If you haven't looked at it, Contour is an Umbraco plugin that does exactly what you need. See here for more information about Contour.
However, for more control I use PetaPoco or more recently NPoco (via NuGet) and also Autofac to inject the Database (analogous to DataContext) into the constructor of my Controllers.
This is super easy and if you aren't already using an IoC container like Autofac in your builds I would highly recommend looking into it. Especially if you stick with EF, as you could ensure that a single DataContext object was created and disposed for each request, making sure that you didn't have multiple contexts floating about.
I'm writting an application that has many Ajax widgets (Kendo-UI to be percise). It's starting to get messy to have all those Ajax responses without the standard controllers so I was starting to consider making each entities their own controller. If I'm taking the time to do this, I figured I might as well go foward and do those as WebAPIs since I was planning to do this in a not so close future, but hey, it would be done already...
So my question is: Is it a good practice to use an MVC application's own Web API as a Ajax Widget feeds or is there any reason to stick with standard Controllers?
I've seen some arguments about performance, but I don't think this applies to this situation. I believe it was more of a "Controller calling WebAPI" situation which has obvious performance hits. But since it's already a client side Ajax call, weither it goes into a standard MVC Controller or a WebAPI controller shouldn't change a thing, would it?
Edit
Additional information regarding the project:
I am using Entity Framework for the data access.
I have a repository pattern going on with UnitOfWork.
I am using proper a MVC structure (EF POCOs AutoMapped to DTO POCOs in the repository and fed into View Models by the controllers)
This is a MVC 4 project on .NET 4.0
There is a lot of database relationships (specially for the object I'm working with at the moment)
I don't know about "good practice", but it's certainly not "bad practice". I see no difference whether you do it in the app or a different one.
I think its a good thing but only if what you are doing in the API is kept as generic as possible to other applications and services can reuse the API.
Both the applications I have written and continue to maintain use pretty much the exact same stack as your app.
I have recently re-factored one of the applications to use the API for all the common things like lists that I'm binding to Kendo ComboBoxes etc. in my views. Its a fairly large application that re-uses a lot of the same lists such as states, priorities, complexities across various Entities and views so it makes sense to put those in the API.
I haven't gone as far as going the whole hog through. I draw the line with things like this:
public ActionResult GetAjaxProjectsList([DataSourceRequest]DataSourceRequest request)
{
return Json((DataSourceResult)GetProjectsList().ToDataSourceResult(request), JsonRequestBehavior.AllowGet);
}
That is very specific to how the Kendo Grid wants the data back. Nothing else I have connecting to this app will use this data in this format so I keep it in the controller.
In short... I use the API for common things within the same MVC app and things that I allow to be used by other applications or services, like Excel.
Can anyone point me to some good resources that can help me understand the best way to work with hierarchical data in ASP.NET MVC 2?
I have an application under development that requires an interface allowing users to add, remove and modify children and grand-children of my root object. The user can make multiple changes without persistance. Only when they click "Save" will the entire object graph be saved.
I've seen one article that serialized the object and stored the data in a hidden field on the form but that seems really cludgy and I am dealing with a lot of data.
If I was doing this in standard ASP.NET, I'd be looking at using child windows and the like to display the edit pages and maintain an instance of the object being edited in Session - which is bad in and of itself. But I've been told we are using MVC as we are standardizing our platforms (but not moving up to MVC 3 yet).
Essentially I need that app to display the properties of my root which includes a child collection of objects. The UI should allow the user to add new items to the collection, remove existing items and 'open' an item for editing. These child items also contain their own list of grandchildren that is editable as well. All of this needs to go on without round-trips across the wire to persist data (its a distributed architecture with all data access behind a WCF service interface).
The examples on www.asp.net all persist the data each time a single change is made, i.e. each postback. But, that would require major schema changes and extra code to deal with temporary objects versus committed objects plus the overhead of the service calls each time. I'm looking for a better solution.
Have you considered looking at any client side libraries like Knockout.JS? I've found that it is excellent at manipulating collections and posting the final version as JSON. Here is an example of what you can do with it. Here is an article about how to integrate it with MVC 2. This is my absolute favorite JS library.
What is the best way to structure a VB.NET Windows Forms application so that code can be reused and the application can be extended easily?
I used to create lots of new forms. This lead to lots of repeated code and forms which did similar things.
Now, for forms which do similar jobs, such as view/edit/delete items from a specific database table, I create a form with the required controls, have the form create an instance of a class with parameters such as a collection of the controls and a string containing the database table name. Then the individual controls call functions of the class.
Advanced forms will inherit and extend this basic form class.
Has there already been work done in this area?
Are there books / articles available which discuss the options available on this topic?
I had great success with this Passive Screen pattern.
In my opinion, the big problem of the traditional MVC architecture is that people stuff way too much into the form classes. This increases the amount of manual testing you have to do.
The more automated testing you can do after you compile, the more bugs you will catch at your desk. In a complex application, the side effects from even minor changes occur all too often.
The trick to solving this is making a controller assembly that the form assembly (or EXE) references. Every form has a corresponding class in the assembly. Clicking a button will call ThisForm.ThisButton(<args>) which will then fire objects lower in your framework. Each form implements an interface so that, if the controller class needs additional information from the form, it has a interface to retrieve it.
Then for your unit testing you simulate an operator performing complex operations by implementing dummy classes to fire events and feed information to the controller classes. The controller classes don't know any different as the dummy classes implement all the expected interfaces.
There is an important exception and that is for trivial dialogs. For dialogs that have a few check boxes I feel this organization is overkill. I use the command pattern a lot. So in the assembly where I define the Command objects, I put the SIMPLE dialog associated with that command. How simple a dialog has to be to get this treatment is up to you.
I like to structure my applications as follows.
Utility - This is an assembly that has stuff I use all the time - Math functions, file function, etc.
Objects - This has the specific objects I am using for this application.
UIFramework - This defines all form and controller interfaces.
Commands - This has all the Command objects that manipulate my application objects.
UI - Objects that implement the controller interfaces
EXE - Forms that implement the form interface and calls the controller objects.
You may want to check out a Rocky Lhotka's popular CSLA Framework. It provides a very structured way to implement business objects so you can keep the non-UI code out of your forms. Beyond just separating your business logic though, it provides built in n-level undo, validation, security, data binding support, etc.
The one complaint most commonly directed at CSLA is that it makes test driven development difficult, so that may be something to consider as well.
Something that can help a lot is the use of User Controls. With user controls you can reuse the same UI in different forms. Also, you can have many user controls on one form, so if you have a form with a tabcontrol that has 5 tabs, the content of each tab could be a user control, so instead of having hundreds of controls all mixed up in one form, each user control has its own controls and validation logic, and you end up with just six controls in the form: the tabcontrol and the 5 user controls.
This doesn't help in separating UI code from application logic, but it enables you to have small, structured entities instead of forms with thousands of lines of code.
What is the purpose of the code behind view file in ASP.NET MVC besides setting of the generic parameter of ViewPage ?
Here's my list of reasons why code-behind can be useful taken from my own post. I'm sure there are many more.
Databinding legacy ASP.NET controls - if an alternative is not available or a temporary solution is needed.
View logic that requires recursion to create some kind of nested or hierarchical HTML.
View logic that uses temporary variables. I refuse to define local variables in my tag soup! I'd want them as properties on the view class at the very least.
Logic that is specific only to one view or model and does not belong to an HtmlHelper. As a side note I don't think an HtmlHelper should know about any 'Model' classes. Its fine if it knows about the classes defined inside a model (such as IEnumerable, but I dont think for instance you should ever have an HtmlHelper that takes a ProductModel.
HtmlHelper methods end up becoming visible from ALL your views when you type Html+dot and i really want to minimize this list as much as possible.
What if I want to write code that uses HtmlGenericControl and other classes in that namespace to generate my HTML in an object oriented way (or I have existing code that does that that I want to port).
What if I'm planning on using a different view engine in future. I might want to keep some of the logic aside from the tag soup to make it easier to reuse later.
What if I want to be able to rename my Model classes and have it automatically refactor my view without having to go to the view.aspx and change the class name.
What if I'm coordinating with an HTML designer who I don't trust to not mess up the 'tag soup' and want to write anythin beyond very basic looping in the .aspx.cs file.
If you want to sort the data based upon the view's default sort option. I really dont think the controller should be sorting data for you if you have multiple sorting options accessible only from the view.
You actually want to debug the view logic in code that actuallky looks like .cs and not HTML.
You want to write code that may be factored out later and reused elsewhere - you're just not sure yet.
You want to prototype what may become a new HtmlHelper but you haven't yet decided whether its generic enough or not to warrant creating an HtmlHelper. (basically same as previous point)
You want to create a helper method to render a partial view, but need to create a model for it by plucking data out of the main page's view and creating a model for the partial control which is based on the current loop iteration.
You believe that programming complex logic IN A SINGLE FUNCTION is an out of date and unmaintainable practice.
You did it before RC1 and didn't run into any problems !!
Yes! Some views should not need codebehind at all.
Yes! It sucks to get a stupid .designer file created in addition to .cs file.
Yes! Its kind of annoying to get those little + signs next to each view.
BUT - It's really not that hard to NOT put data access logic in the code-behind.
They are most certainly NOT evil.
Ultimately, the question you ask yourself is this:
Does this code A) Process, store, retrieve, perform operations on or analyze the data, or B) Help to display the data?
If the answer is A, it belongs in your controller. If the answer is B, then it belongs in the view.
If B, it ultimately becomes a question of style. If you have some rather long conditional operations for trying to figure out if you display something to the user, then you might hide those conditional operations in the code behind in a Property. Otherwise, it seems like most people drop the code in-line to the front end using the <% %> and <%= %> tags.
Originally, I put all my display logic inside the <% %> tags. But recently I've taken to putting anything messy (such as a lengthy conditional) in my code behind to keep my XHML clean. The trick here is discipline - it's all too tempting to start writing business logic in the code behind, which is exactly what you should not be doing in MVC.
If you're trying to move from traditional ASP.NET to ASP.NET MVC, you might aviod the code behinds until you have a feel for the practices (though it still doesn't stop you from putting business logic inside the <% %>.
There isn't a purpose. Just don't use it except for setting the model
ViewPage<Model>
See this blogpost for more info.
At this Blogpost is a working example of removing the code behind.
The only problem I'm stuck with is that it is not able to set namespaces on the class.
The codebehind provides some of the strong typing as well as the intellisense support that you get in the view. If you don't care about any of these two features, you can remove it.
For example, I typically use the NVelocity ViewEngine because it's clean and pretty straight forward.
This is a great question. Doesn't MVC exist in the ASP.NET environment, without using the specific MVC pattern.
View = aspx
Controller = aspx.cs (codebehind)
Model = POCO (Plain Old C#/VB/.NET objects)
I'm wondering why the added functionality of MVC framework is helpful. I worked significantly with Java nd MVC and Java Struts several years ago (2001), and found the concepts in MVC to be a solution for the Internet Application organization and development problems at that time, but then found that the codebehind simplified the controller concept and was quicker to develop and communicate to others. I am sure others disagree with me, and I am open to other ideas. The biggest value I see to MVC is the front controller pattern for Internet development, single entry source for Internet Application. But, on the other hand, that pattern is fairly simple to implement with current ASP.NET technologies. I have heard others say that Unit Testing is the reasoning. I can understand that also, we used JUnit with our MVC framework in 2001; but I have not been convinced that it simplifies testing to use te MVC framework.
Thanks for reading!