We're converting from ColdFusion to ASP.NET 4.0 and we just don't know which route to take with setting up our classes.
In college I was taught to break everything up into separate Data Access Classes and Entity Classes that speak to the DAC. To me, that's the best option for a team that needs a lot of control over their classes and needs to reuse multiple items.
Then there is LINQ... Sure.. It's great and fast! I have no problems writing my own queries though. To me, it's not something I really need. None of us on the team need the help from LINQ actually.
I would think we should be using folders that contain our DAClasses and folders that contain our Entity Classes. Then we would have our actual .aspx presentation pages.
Any ideas on which route we should be taking?
If you're going to go through the pain of moving from an existing platform to a new one anyway, look at ASP.NET MVC.
The Model-View-Controller methodology is a potentially cleaner way of thinking about web development, and it achieves the separation of concerns your team seems worried about.
On a different note, you make it sound like LINQ and other such technologies are crutches. They are not unless you use them that way (as in, not being able to do data access without it). They are there as a tool to make your life as a developer easier and development go faster.
Knowing how it works is great, if you didn't know I would be of the mindset that you shouldn't use it. But you clearly state that you do understand it, so why not leverage it?
Related
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What’s your choice for your next ASP.NET project: WebForms or MVC?
Can you list some reasons that would make you use ASP.NET webforms for a new project, instead of MVC? I've heard a lot about the opposite, but not things that are done easier or better with webforms. I'm not talking about developer preferences here, but rather technology features and how they map to project features.
The only argument for WebForms is the need to design highly complex (read cluttered) interfaces with a whole lot of interconnected elements which in all or in part should react to changes in other elements.
A typical example would be some enterprise application (from SAP or smaller vendors). They usually have interfaces bordering madness. You'd have a hard time trying to synchronize the controls manually with JavaScript if you were on MVC. With WebForms it's by far easier.
Whether it is a good idea to build such interfaces is another matter entirely.
In WebForms element events trigger a page postback. They go to the same url and are processed in a unified manner. This is what makes the architecture very scalable.
With MVC to accomplish this you would have to set up a bunch of service urls to handle posts from different controls, then process those posts and update view models accordingly. This all involves a lot of trickery and juggling. Not that it is not doable - it is, but not on a big scale. This approach would not be scalable. Sooner or later you will arrive at the understanding you'd need to build your own framework in the direction of stateful object-oriented HTML/HTTP abstraction like WebForms.
A few things that could push me (back) towards WebForms:
I need to produce something that can be taken over by someone who isn't primarily a web application developer (say a WinForms programmer), and the app could substantially be maintained through Visual Studio's Forms Designer. The IDE support makes the development model closer to that of WinForms.
An app that needs to look Ajax-y but will be maintained by someone who won't learn JavaScript. I think things like the UpdatePanel (while horrible in so many ways) are actually pretty good for that scenario.
Possibly for some kind of demoware, again because of the IDE and ASP.NET AJAX. Fairly quick to knock up some reasonably smart screens without too much thinking.
I need a powerful CMS and need to stay within .NET. At this point it looks like there's better choice in WebForms than in MVC (though hopefully that's changing).
I'm working with a team who are already familiar with it and aren't going to learn MVC.
Of those, probably the CMS is the requirement I could think of right now that would actually make me use WebForms.
If you only know webforms MVC comes with a learning curve so you will need to spend quite some time training (or risk making serious security or performance errors)
You need a tiny little app NOW It probably is quicker to build a throw away mock application in webforms if you go for the anti-pattern. E.g. SqlDataSource, Logic in your code behinds etc.
Rich controls GridView is an excellent control, having sorting etc all built in for you with little code needed as long as your custom requirements are small.
Lack of web development experience Web forms is just easier. It takes more concerns off your plate. Much better for a newbie as its tough to go wrong.
Having said that, if you know what you are doing or have the time to learn and you want to build a long lasting site, MVC is soooo good. And more fun too.
I'll add that there is nothing really wrong with web forms. It's perfectly possible to build high performance app with it. It's just times have changed since it first came out and MVC has addressed those changes well.
Personally, i find MVC very good for admin-pages. because they usually have a load of tables, and are made for data input and editing. MVC is 'made' for those things, so it's going very fast making those pages.
webforms I use for more complex things, like the User-end of the site. the site i make shows courses people can take. the registering for a course is a 5 step procedure, which in MVC, I have no real idea how to do it. I'm sure it can be done in MVC but I think it's better/faster in webforms.
however in the end I do like MVC more. It feels so much cleaner to work with.
The only time i would consider going with Web Forms in a new project is if there was a component created for Web Forms that solved a specific problem that would be much harder to solve using MVC.
I can no longer see any advantage of Webforms over MVC, apart from some upskilling effort which should not be prohibitive.
[Originally I believe MVC wasn't compatible with webcontrols, so wishing to use Dundas chart control for example wasn't possible. That would have been a good argument for using webforms depending upon your requirements. But I believe this is no longer the case, and anyhow, you can include webforms in your MVC project as a worst case.]
It depends!
The difference between WebForms and MVC is if you can TDD and control the complete markup.
I have my existing web site developed using ASP.NET.
It's college management system. Now I need to redevelop it on MVC2.
What all changes do I need to do?
I am little bit aware of MVC and have done some exercises also.
Thing I know is I can keep my database intact but there will be massive changes at other places.
WHat will be the better way to minimize the changes?
MVC is a very different concept from event-oriented WebForms. There's good chance you will have to redo the frontend completely.
Try to find out if there is anything resembling data access layer and the business logic layer. If so, you can keep them (at least partially) and reuse their methods.
However, if the current application is not well structured and looks like a giant code blurb (with no layers, parts of the code talking to any other part at will, page methods going directly to the database etc.) it may have to be redone entirely.
If the application is now heavily relies on data-bound controls, you're screwed. You will have to recreate a lot of functionality by hand.
You should be able to refactor the middle tier (if you're using a multi-tier approach) into controller/model while keeping the UI intact. Once you've done that, throw away your UI and write a proper View. Try using LINQ-To-Sql for the backend.
I'm currently working on a high-traffic online search site.
They have various changes they want to implement over time, and they've indicated that ultimately they want the site re-done in ASP.NET MVC.
Currently the site is an ASP.NET WebForms project; however true ASP.NET controls are rarely used. Instead there are lots of server-side tags - i.e. <% ... %>. The code in these tags will usually be a call to a static method in a static class or a fragment of C# code that generates HTML.
Many of the static methods generate HTML by appending text to a string-builder and returning it as a string.
I understand the concept of a 'Helper' method, but I don't like the idea of the HTML being rendered by concatenating it to a string variable. I think they'd be better off using 'Partials'.
The thing that concerns me is that it's a pretty complex site, and I'm not sure if a complete rebuild of the site in ASP.NET MVC is a good idea.
In spite of the bad structure, it's not really that hard to add the new features that are being requested. (Perhaps because I've had past experience working with difficult code).
However I think there's a risk that at some time in the future, a requirement will come along that will be very difficult to implement unless we do a complete clean-up of the code-base.
I want to put this question out there and see if anyone's faced a similar issue, and how you dealt with it.
Also what are your thoughts on doing the re-build as a 20%-time side-project? Are there any downsides to doing it this way?
Wow, this is some project.
Personally I think any site written in ASP.Net will need to be totally re-done as far as the UI is concerned. MVC does it a whole lot differently.
Your business logic on the other hand should be ok though me thinks so long as you have seperation of concerns and it's not bound to the UI.
Data access should be ok and probably needs minimal touching. But that again depends on how tightly bound your web site is.
I think the best approach is to spend some time looking at how MVC does business and do a critical analysis of what it would take to convert and then begin converting all the layers above the UI in preperation.
Get your foundation in place and maybe even, if possible, use the MVC framework already. Again, only if you can and only if viable.
Doing this as a side project would work I think because you can take some of your libraries and begin converting them in preperation for the mvc conversion.
But be mindful that once you have converted a project/layer that you (do) implement it else it runs the risk of being forgotten or changes get made to the other layer that then need to be coded into the new etc. You know the traps.
As for the UI, that's going to be the big one especially if you use a lot of asp controls. You maight want to spend a lot of time evaluating the UI and come up with a list of controls that you either need to replace or write. Then you can begin to see a pattern and get some consistency going.
If you have a lot of code in your code behind, you may want to begin moving this to another layer as this will help later on when you create controllers etc. They can then instantiate your new layer and all should be good.
That's all I can think of from the top of my head. I'll edit or comment as I think of things.
Hope this helps.
If I have that project and I was asked to redo it from scratch, I will not use MVC to render the UI, I will use Web API/OData to host all the backend, and will use any good Front End to draw the UI, Angular will be a very good option.
Having it as a side project is good only if the pace of changes and new features in the old project is less than the progrress done in the new project, you don't want to end up with doing duplicate effort and at some point you will have to code freeze the old one.
Also, you have to consider any data migration if you will have to change the data storage option.
Recently our newest web designer asked me why we use ASP.NET for our website. Reading through his question to the real one, I started thinking about it myself. Why are we using ASP.NET for web development?
The problem we find so far is colaboration between the design team and developers. Typically our designers create some snazzy cool look crayon laced web pages, then show them off for approval in all their glory. Once approved, the developers rip the HTML out and shove it in to ASP master and detail pages, and huzzah! out comes pretty website.
Since Dreamweaver doesn't play nice with Visual Studio, this is the same process for even small tweaks and changes. I would prefer to just write the backend and let the designers draw the pretty pictures and fancy CSS. Our current websites have plenty of reason to use ASP on nearly every page, so I can't do half in HTML, the other half in ASP.
I have no aversion to doing something else, another language, CMS platform, some other random buzzword, etc...
What are your experiences with this design situation? Are we doing it the hard way? Should we consider alternate platforms and languages? Are there any good, proven ways to allow designers to work on ASP (while still using Dreamweaver)?
Start learning Asp.net MVC as soon as possible. Designers will love you for that. :) And you'll be up to date with new development technologies that will also make your solutions much more robust and less complicated.
But otherwise. Designers should be able to read XHTML fluently. Learning asp.net semantics shouldn't be too hard. Then give then Visual Studio where they can manipulate content. As long as they know how asp.net web forms work things should be fine. They'll probably be able to do majority of things using just CSS. I know I can. Sometimes I do have to check resulting HTML, but it works.
Aside from Wicket (a java web framework), I don't know of any framework or language that would allow designers to continue to work on the design once developers have started to add logic to it.
I would suggest two things though:
Use a MVC framework - ASP.NET MVC, Ruby on Rails, Django, etc since this allows for far more separation of presentation and logic
Keep your presentation layer as stupid as possible and use helpers as much as possible or even better, put the logic in the domain objects. The view should only show or get data with absolutely no logic for processing data, this will keep the pages much more designer friendly.
I find your question very interesting because no matter what kind of technology the project uses the interfaces between the different roles will always cause some friction. I am not sure if there is a technological solution to this communication issue because the designer and developer speak literally different languages.
Depending on the skillset of your designers and developers an additional layer might help you out. I do not know how ASPX works but i am sure there will equivalents to the concepts of other technologies.
In case you have mainly static content which can be expressed in XML than you could provide the backend which delivers the content in XML with a defined Schema and your designers could describe the transformation in XHTML and CSS via XSLT. Given that your designer are capable using XHTML and CSS the addtional effort to learn XML and XSLT is not that huge. I find this solution much powerful than template languages which try to emulate the richness of the serverside scripting language in their own limited constructs. In case you have dynamic elements on the clientside like DHTML, AJAX or you name it you could define your own xml tags which are transformed to richer client side objects after the designer did their work. I guess the designer will understand the usage of these special tags and you provide the proper translation into client side objects.
I used this approach with some coworkes based on PHP. PHP was only the driver for the transformation. The content was assembled into xml with special tags which were transformed into XHTML and CSS via XSLT. Once the objects and the transformation for the different objects is defined you build up a library which can help to shorten the developement cycle of new pages of you webapplication. The benefit of the extra work is, that you designer can change the layout of the page without ever touching you server side code.
Maybe this helps.
Consider using either Expression Web or SharePoint Designer. The latter is now free.
I know you specify dreamweaver, but have you looked at Blend? It plays very nice with Visual Studio and is quite a nice app. to work with.
I have the need to build lots of sites that are very similar, but not exactly the same, using ASP.NET 2.0.
I'm trying to find the best way to make generating these sites quick and easy.
The sites will be used to collect information about a user, and there will be multiple steps for each site.
The sites will all collect similar information, but some sites may require less or more information than others. Additionally, certain form fields will need to be populated from different database tables, based on the site.
I would like to use a Microsoft patterns & practices solution, but I'm not sure that there is one that fits this scenario.
My current thinking is that I will put as much business logic as possible into an external assembly and then write a custom Web user control for each step for each site. I will include these user controls in a master page's Panel control.
I don't like this solution because each site will be nearly duplicating the code for the other sites.
How can I improve upon this design?
The main obstacle is that the sites are similar, but sufficiently different.
Thanks!
Alex
you can create base classes which handle all of the common functionality and then have your site specific controls inherit from their respective base classes and then implement their specific implementations.
We face this problem all the time. What we do is to have a common library that all our sites use, and to bury shared functionality in classes or utility modules in this library. Each site can then use those objects or utility functions as is, or extend the common classes. Keep in mind that these shared classes can include all kinds of things, including code-behind for pages and user controls that you can inherit from and extend.
Deciding what goes in the app and what goes in the common library is one of the hardest things about our business, though. Put it in the common library and you lose flexibility; put it in the app and you risk having duplicate code to maintain.
If you have a fairly complex database setup, it might be worth your time to come up with a framework for specifying your db schema in XML and having your app enforce that schema and build any additional SQL infrastructure that you need based on that definition (e.g. utility views, stored procedures, etc). We did this and it resulted in a huge productivity boost.
Have you looked into Monorail (www.castleproject.org) this is an implementation of themvc pattern, similar to Ruby on rails with a few nice view engines, I prefer Nvelocity.
from castle project as well you can use n implementation of ActiveRecord that makes life real nice. if you are on that trail also have a look at coln ramsay screencasts .
To be honest all ms solutions are real fat
another great thing about the castleproject is that is totally open source so you can learn loads from their code
How about using an Application Framework like DotNetNuke or mojoportal?
They both provide flexibility and enable you to develop websites very quickly with common functionality. Leaving you to develop custom modules where the functionality you require may be different. There are also thousands of other modules that can be bought which provide excellent functionality.
However we chose to use WCSF and enhanced upon it.
All the above mentioned projects are open source and some good examples of code to learn from.
I know it may be a late answer but I hope it helps