Sunday, November 27, 2011
First we take this partial view
Then we add it to the main view like this
Next we need to have a Action to call that returns the rendered view with updates
In this case we update the model and return the specified partial view with the updated model.
it’s fairly simple and a lot like what we did in the Easy Ajax post, the major difference is we take the returned rendered partial view and replace the existing rendering of the partial view using JQuery’s .html(), this replaces the existing content with the passed in content. This is a very simple and effective way to manipulate your pages.
As always here is the source code for a sample project using it
Saturday, July 16, 2011
More often then not it would blow up and so I would spend the first 1/2 hour every time I worked on the project getting things to work again. Well no more!
FluentMigrator is based on Ruby Migrations, with a fairly simple syntax. The db classes have the attribute [Migration()] that specifies the version, and inherit from the Migration class, and override the two methods Up and Down.
Migrating Up and DownThe Reason for the Up and Down methods is very simple; if the version your migrating to is higher then the version of this class it executes the code in the Up method and if the version is lower then the code in the Down method executes. Basically whatever you do in the Up is undone in the Down.
Setting The Version NumberSomething else you may have noticed is in the Migration tag the version number is fairly large, to make versioning easier on a team, I’m not using consecutive numbers but the date and time(using 24 hour time) of when the I added this class, so the the example class I created was on 6/24/2011 at 23:24 10. The current version number is also stored in the DB, making it very simple to see what DB version you’re on, this can come in handy if your code is based on a specific DB version you can do a simple check to see if you have the correct DB version.
Keeping version iterations smallJust like when creating a business logic class, you should follow the single responsibility principal, and have each class do only one thing, this may mean having a lot of classes but on the other side it will make it a lot easier to keep track of what each version added, modified, or removed.
Adding stuff to the Data BaseUsing the Fluent api allows you to very smoothly add tables, columns etc. in a very readable way. If you look at the Up method in the above example you can see how easy it is to add a table with columns. This makes it very easy to add your own extension methods to short had it even further. Here is an example for creating an identity column and a table with time stamps:
But the api doesn't have everything you need so you have the option of adding in strait sql using Execute.Sql(). like this example:
also you can call sql files like this:
Adding DataThe next step is to add some data. This could be some sample data for development, a larger dataset for QA, QA data for a specific type of customer, or base data for production. By adding profiles you can abstract away what data you want to add for specific function. This is not where you add data for things the should be constant, things like lookup tables should be handled by a versioned migration class. Here is an example of a profile class:
Just like a Version class it inherits from the Migration class and has an up and a down method, this way when you add one profile it will remove the other profiles.
Deploying/Migrating Your Data BaseDeploying or Migrating your data can be done with a console app or with a build runner like MSBuild, nAnt, or Rake making it easy to integrate into your existing build process. For this example we are going to use nAnt. Here is an example nAnt build file:
- database – this specifies the type of DB (sql, oracle, sqllight, mysql, etc.)
- connection – this specifies the DataBase your going to connect to and with what permissions
- namespace – this is the application namespace your going to run allowing you to migrate multiple DB in the same project
- target – this is the .Dll you’re calling to migrate from
- Profile – this is what profile your loading
- task(optional) – this is how you specify what version you want to build, or if you want to roll back, etc.
Thursday, July 14, 2011
This may be just an outsiders view but ruby devs seem to be more dedicated to pair programing, TDD, CI, etc. and basicly more interested in writing software to make a living vs. where in the dot net comunity it feels more like developers write software just to make a living, there are a few leaders that that push these ideas, but for the most part it seem more previlant in the ruby community.
So my real question is, why? is the ruby stack just more attractive to people of this disposion? is it just becouse dot net is just more widely used and thus just has a wider spectrum of developers in it? Is it just becouse I have a very limmited view of the ruby community and only seeing the cream of the crop, or am I just somewhat jaded and only seeing the negative in the .net community? To this I don't have a good answer.
So the next question is how do we get the passion in the .NET dev stack? it's not like there is a lack of interesting things to learn and build, can we do more community work? Boise has a .NET user group (netdug), a software developers group(bsdg) that is mostly .net developers, and a code camp every year, but for the most part it's the same people group presenting. my open question to the group is how do we get more people interested in presenting, do we start younger? maybe start youth dev groups? maybe as a group pressure each other to be more active? For my part, I need to step up and do my part, and rededicate myself to blogging.
Monday, May 23, 2011
One of the core concepts of well architected code is being decoupled, but like so many of the good things in life if you do it to much it becomes bad for you.
Recently I worked on a piece if legacy code that from the UI to the Dal it passed an object though 7 classes and was converted from one object to the next 5 times. Their wasn’t any real difference from one object to the next. In some cases it was pulled from the data object and each item was passed as a parameter into a method where it was then put into a new object. The result was next to imposable to debug, even harder to read, and in a lot of places just plain sloppy.
In an earlier post N-Tier Design Revisit part 2 – Data Entities I talked about how data entities, poco, or dto (they are all basically the same thing more or less) work, they go from the UI though the Biz and to the Dal and back again. This creates a message that is passed, your code is still decoupled because the Data Entity basally contains no logic, it’s just holding data.
Wring an application is kind of like growing a garden, if you take care of it and maintain it, it stays nice and easy to maintain. If you neglect it it becomes difficult to maintain and will over time die. Decoupling is one of the things you do to make it easy to maintain your application, kind of like watering it, and just like watering it if you do it to much you’ll kill it.