I have been set a new project at work and have been given the code beforehand to give it a good look. Since time is limited, can anyone please give me the best way to get a good feel of the project. What are the things I should be looking for within the code?
Thanks.
Well, first I'd get the app running and get a sense of the functionality (the business functionality) of the application. If you're not familiar with the business functionality, keep notes on your questions.
Next examine the code. things like:
1. Database access methodology (ASP.NET Core, Linq2SQL, EF, NHibernate etc.)
2. Take a look at the database and the data model
3. Examine the areas you're not comfortable with in regards the ASP.NET/C# etc.
Keep a note of questions you have through this phase. If they want you to hit the ground running, you'll need your questions answered. Asking the right (intelligent) questions shows you've spent time examining the code (as they would expect)
Set a breakpoint at the page_load or init event handler of a page of interest and step through the code (F11) to see where it goes and what it does.
Related
I've tried to do my homework on this...
I'm migrating a site from classic asp to asp.net 4.0
Before I rework all the code, I wanted to get clarification that the way i think my database code should be updated is fairly correct. (I'm using SQLClient objects)
First, when old code would use forward only recordsets or access single record/value, I'm fairly sure i'd use SqlCommand and SqlDataReader. That is pretty straightforward.
Now, when my old code navigates a recordset (movePrevious, find, etc.)... I believe the way to go is with SqlDataAdapter and DataTable to retrieve the data and DataView to filter/find/navigate the data.
I'n looking to do a quick migration... i don't want to get too bogged down in the new entity framework... so - just trying to stick with similar objects/logic.
I know this is one of those questions that doesn't really have a right/wrong answer... and I think that is part of my problem in finding an answer - there are so many.
Thanks,
bill g
I answered something similar here.
You only really need to know about the database bit here. For you it's a really good point to start as you mean to go on.
It terms of how deal with the data returned, it's up to you. I'd recommend custom class style dataset approach which will make life easier in the long run but of course in the short term, you'll have to generate them all which can be made easier by CodeSmith*. That in itself has an upfront cost but will, again, save time in the long run.
*Other code generation tools are available.
If your main issue is the database I propose to move and learn the Subsonic 2 (not subsonic 3, too slow) or any other DAL.
See here some examples:
http://subsonicproject.com/docs/Main_Page
Take some time to understand it, make some tests, see what really do, after wille you can't do with out it, but you need some time to understand the logic, and setup it to your project.
Get this project to play with and see some dal in action, ready to run.
I'm still trying to understand and use Use Cases and Test Driven Development, but having a hard time crossing the line. I'm hoping someone can provide a good example of how setting a datasource and/or databinding a gridview could be accomplished using Test Driven Development.
Here is my pseudo approach at it.
Create an aspx page and add the gridview control to it.
create a method in the code behind called BindGrid(datacollection,gridview) that passes the collection and gridview to a method in a class outside my website so I can actually write the Unit test for the method, and returns a databound gridview.
On the BindGrid method, I right click and select "Create Unit Test" which creates a new test project for me with an outline test for my BindGrid() method.
Now I guess there are a number of test I could write, for example: testTrueDataCollectionBindstoGridView() to see if the collection datatype actually binds? I'm not sure the other test to write?
This is how I currently understand I would go about TDD and Unit testing my example. It feels very clumsy and I'm hoping for some feedback as to what I'm doing wrong, and ideas for improvement.
Thanks
Update:
I've decided to try to simplify my question in hopes of getting more ideas.
How would you go about writing a test for a collection binding to a control? For example say I wanted to bind a dictionary to a drop down list. What test should I be writing, and how would I go about writing them?
Thanks
To some extent, your question describes why the ASP.NET MVC frameworks was created. It is very difficult to write tests against the ASP.NET Web Forms model (of which the GridView is part of). Also, you seem to be close to writing tests to test the Framework itself, not the code you are writing. If you go too far down that path you will write tests forever and never release any code. It would be more productive, in this case, to seperate out whatever code you used to generate the collection you are binding to the GridView and thouroughly test the scenarios around creating that (and especially any exception conditions and possible conditional logic) and trust that the framework binds the data to grid correctly. If the data generation method can produce any exceptions that you want to handle at the UI-level, try test how your code handles that, but again, this is where the MVC frameworks are helpful, b/c it is extremely difficult to test code that needs to be run within the Web Forms lifecycle.
Just speaking in general terms, since I'm mostly doing Java these days and not .NET stuff. I find that TDD does feel rather clumsy at first for most people, but give it some time, and see if you like it or not.
As far as writing tests, take this general approach. Create a method that you want to test, but without any body to it. Create a test that exercises some particular behavior, and keep it simple. Run the test, and it should fail (run red, assuming your IDE does that). Then, write the line or couple lines of code that make the test succeed (go green). Now, write another test, and repeat. If you have conditionals, make sure all paths are tested. That is, write one path, then the other, writing the test for each first.
When you have a method that works the way you want, you can now refactor it to your heart's content, since the test will always be there to check your work. Look at the method. Perhaps there's 4-5 lines that go together, and could be pulled out into a method. Give the method a good name, so that when you're reading the calling method, the name tells you what's going to happen without drilling in. There are other possible refactorings, especially inasmuch as you can see design patterns that you can leverage.
Make sure you re-run the tests frequently as you proceed with your refactoring.
TDD is about adding functionality. It encourages minimal logic in UI components - mostly they should be pure delegates to the code that does the real work, that you can test.
I would recommend, for the purposes of learning TDD, don't bother writing tests about UI behaviour (eg binding data to a control).
To learn TDD effectively, I think a good place to start is try a few code katas. A code kata is a small problem which you do repeatedly. The solution you develop is not the important thing - learn from the process of getting to the solution. So do the problem 10 times, and deliberately choose different designs for the solution each time. TDD is about the process.
There is a list of katas here: http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
The Roman Numerals kata is a good one, but just pick one that appeals to you.
I've been looking into ASP.NET Dynamic Data and how it does scaffolding and routing. I've only scratched the surface, but it's looking like I'd have to create a template for each table that I didn't want to display all columns the same way.
My first impression after looking at dynamic data is that it would seem like less time on the programmer to have to edit one-time generated user controls rather than build a template for each table that doesn't have a uniform display behavior.
What proven solutions are people currently using that help ease the laborious tasks of creating ASP.NET CRUD type user controls?
Thanks
In ASP.NET webforms we use CodeSmith. From a single entity we generate admin pages, codebehinds, service layers, data layers and db stored procedures. All in a matter of seconds. I'd recommend you check it our for quickly building the crud in your apps.
We're actually working on our own code generation tool. It has already proven to work perfectly on the lower layers and now we're on the way to extend it for the presentation layer, that is for generating user controls.
I've not looked into dynamic data (although I'd like to when I have some time) but my biggest fear is always to lose flexibility. The problem is that these front-ends are then maybe generated dynamically each time based on some template and editing, especially bringing in special customer wishes becomes quite difficult. For small standard apps it may work perfectly though.
What we're therefore doing is to "generate" these usercontrols based on a set of standard custom server controls we've developed, but we'll generate just the first time from some static information about the entities in our application. Then you can continue customizing.
Such systems should help the developer, improving his development speed, doing the initial awkward work but then they should give him the flexibility to modify till the maximum. They should not add additional complexity...
I used .netTiers CodeSmith templates long time ago (years) and it was proven so strong, so, it must be more than great now.
I know a (big) company who have built a customization engine (allowing GUI for internal company options) around those templates to use them in most of their applications and were so successful.
I've used http://www.ironspeed.com/ in the past which has been great. Saved us MONTHS of time on our last project which has a big DB, so the cost is worth it. But it looks a bit ugly and can be tricky to update the DB schema once you've generated.
Obviously not much widespread use out there other than whats provided in Visual Studio.
Have a look at Blinq.
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 am working on a design spec for a new application that will be heavily workflow driven.
Before I re-invent the wheel, is there a decent lightweight workflow engine that plugs into ASP.NET already around?
Basically, I'm looking for something that handles moving through a defined set of workflow pages while handling state management automatically.
If this isn't around already, I'll definitely try to abstract the engine from my app and put it on codeplex, as it would be really handy.
Any suggestions?
Note: .NET 2.0, so no WWF, though I think WWF is overkill for my needs.
EDIT: Seems like there is a legitimate need for this, and there isn't a product out there...So I might build this.
Here is what I'm picturing:
Custom Page class called WebFlowPage
All WebFlowPage's are registered in a Workflow mapper.
Each WebFlowPage has some form of state object.
A HttpHandler handles picking the appropriate WebFlowPage based upon the workflow, and populating it from the state object.
Is the workflow dynamic, or static?
If the workflows are simple, you could roll your own workflow engine.
In certain situations, it can be fairly simple, and just a couple of data tables to handle the rules, processing and state.
Alot of workflow engines are built for large scale processing (credit card applications, for example). For small scale, you should at least consider your own, which would eliminate the overhead and dependency of/on an engine.
Not sure exactly what you wish to do here, but Ra-Ajax can easily keep state at least if you want your solution ajaxified...
For reference purposes you might want to check out the Ajax Calendar sample or even the (banalistically implemented) Ajax Wizard sample. It surely beats the hell out of doing it with JavaScript...
And every time you "do something" you're in "server-land" which means you can store temporaries all the time as you wish...
The project is LGPL
(PS!
Yes I do work with it)
Building a custom workflow engine is not trivial, although it may seem simple at first. We've tried that. It depends a lot on the complexity of the logic you need it to cover.
Given the current state of the Windows Workflow Foundation and the lack of another framework that abstracts the workflow concepts, I would choose WF if you need complex logic, asynchronous handling or branches in your workflows.
Tracking your state through the workflow can be accomplished by carrying some kind of xml payload or storing the state in a database,
If your workflow is actually a sequential set of forms that need to be filled in by the user, tracking the steps and guiding the user to the next step can be accomplished with some simple custom solution.
You could take a look at the InRule engine too.
Also, there is nxBRE.
These too are mostly used for business rules.
InRule is proprietary, whereas nxBRE supports RuleML (the defacto standard).
You might need to make your own implementation for the pages, and use the rule engine as the "structure".
At this moment, I know that Sharepoint 2007 supports page workflows (using WF), but this would imply using .NET Framework 3 and deployng sharepoint.
My suggestion would be to use whatever you find more light and easier to use.
I think the term "workflow" is very open to interpretation. I have been working lately with a type of workflow that is very different from what you seem to be describing. Mine is a state machine based workflow where the state of a particular record determines what actions a user can take to move the record to the next step in the business process. So "workflow" in this instance means how the record flows from one state to another until it is finally completed.
Your usage of workflow seems to have more to do with moving a user from one page to another in a linear multi-step process, which is a completely different use case (correct me if I'm wrong). So before coming up with a general purpose "workflow" engine that anyone could use, I would recommend defining a little bit better exactly what types of situations this system would handle.
I've been using this for a few months http://objectflow.codeplex.com. Not asp specific but it may fit your needs
While browsing the web for some workflow & BPM resources, I found the following project: NetBPM. Unfortunately, the project seems to be stopped.
I don't think there is a workflow engine that will automatically handle state for you, but if you are moving through a set of pages like a process such as checkout on an ecommerce site, perhaps the ASP.NET wizard control could help you?
There are few workflow options. "Aspose" and "Skelta" are the offers I´m evaluating.
Fábio
you can use WorkFlow Engine, just read the document and run the Demo.
all of the features you need for a dynamic workflow engine they added in there.