This week, I started working on a prototype of the UI for my event scheduler software to test if it makes sense on a tablet and on a desktop. Since this is a prototype, I’m not putting any effort in the architecture, error handling or on tricky edge cases and business logic for now. What I’m testing out exactly is :
- Displaying an expanded and a collapsed list of sessions.
- Showing an action menu to move the time of the session forward and backward (without saving it for now).
- Navigating in the timeline to see the whole day.
I’m a beginner with the Entity Framework (EF), which is the object-relational mapping tool in ASP.NET: I never had to use a database in my projects since all the data was from web services. Still, I figured I could start the prototype by building a small data model, and use the scaffolding tool in Visual Studio to generate views. This way, I would have an almost free way to create and modify the data for sessions in my test. Also, this knowledge will come in handy later when I build the real thing. This was going to be a breeze…right?
Here is what I was aiming to do as seen in EF. In my model, I’m including only the event itself and sessions (talks) for the event. I’m supposing everything will be in the same room and on the same day for now. Even the event was not really needed, but I wanted to see how relations worked.
Since I learned to work with databases the old school way by first building the database and then connecting to it with my application, I decided that I would create my database first and then generate the model classes from that database with Entity Framework. It seemed the most logical thing to do since I know exactly how I want things to be stored in the database. After a while though, I felt like I was going against the logical flow of things for EF by going database-first:
- First, I’m used to having columns names and table names in lower case in my database, and objects names in CamelCase in the application, but EF uses the same names for both. Even when I renamed thing as I wanted them in the mapping, EF keep using the wrong case in SQL queries, so I couldn’t access any data.
- Second, while Event and Session are great names to represent the concepts of an event to plan and of the sessions (talks) for the event, they are really dumb name to use in C# code. Those class names are already used in the .NET framework used to represent an event (handler) and a browser session. If I keep those names for my classes, I’ll have to use namespaces all the time which is a pain. And as seen with the first point, just renaming the classes and keeping this name in the database wouldn’t work either.
- Third, EF plurializes everything by default, while I’m used to singular table names in my database. I found out about this when I tried to rename my tables SessionInfo and EventInfo in a last-ditch effort to solve the problem above: EF would plurizalize the table names to SessionInfoes and EventInfoes, messing the SQL queries to the database (again).
All those problems keep breaking the project, stopping my progress. Those are solvable for sure, but there is no point to putting up with that crap since there is a better way to do things. So, I decided to cut my looses, generate my database from my model classes and stop caring about the exact structure of the database for now.
As a bonus, going code-first doesn’t required messing with the designer as much: I can just use annotations on my model classes when I want to do something in particular, for example to specify which table names and column name to use. It’s also easier to manage in source control since the code, which is now the reference for the design of the database, can easily be checked in.
Of course, this worked like a charm: I just created my classes from the generated code I already had from my previous tests, generated a database and scaffolding and everything worked on the first try. That will teach my to try and go against the standard for a framework…
Moving to code-first was not enough to fix my namespace problem of course, so I also renamed my classes ScheduledEvent and ScheduledSession. This name is even better than my first choice: when I’ll add features to publish schedules, I’ll probably need a pair of classes such as LiveEvent/LiveSession or PublishedEvent/PublishedSession anyway.
In summary, this part of the project didn’t go according to the plan to say the least. I now have a good headstart on how the model with work and on how to use Entity Framework so it was a good thing, but I didn’t want to spend this much time thinking about the model at this point just for a prototype. It’s not unexpected to have this kind of setback, there are still a lot of unknowns and there are sure to be more technical surprises lying around the corner.
| Reference: | Starting the prototype : building the database from our WCG partner Cindy Potvin at the Web, Mobile and Android Programming blog. |
