Skip to main content

The Theory: Entity Framework Layer Domain Modeling

One of the things I learned from revisiting C#II's project, eDevices was that planning out what your database schema is going to look like is pretty key to determining how easy your life is going to be down the road. In C#II, the focus appeared to be on breaking up the bigger project into smaller iterations that were built on organically--which was GREAT until I tried to implement a feature that hadn't been planned for in an earlier iteration, one that required changing one of the fields on the Policy entity.

I managed to break all functionality because the Policy entity no longer matched what was expected, and I had to completely redesign 90% of my application's business logic to account for this new feature. This led to further frustration when I realized that I didn't properly manage my code first migrations for this series of changes--again, they happened organically during the class without any thought or discussion as to how to go back and make changes.

Had this project been planned out with a full list of requirements from the start and THEN broken into bite-sized iterations (and the class took this approach for valid reasons I'm not going to digress into, lest this analysis is viewed as criticism), much pain and suffering could have been avoided in later iterations. That's the approach I intend to take on this project--end goal clearly defined, then split into manageable pieces that are configured to fit together from the get-go.

Knowing that my EntityFramework layer is going to be the base of my application's pyramid, so to speak, I felt it important to really define what each entity would look like and how they would be interacting with each other. I won't actually rush out and code all of these objects at once, but having the schema I want already defined means I won't be creating an entity class off the cuff that I remember 4 iterations from now needs to be totally different in order to implement a new functionality.
Labels:

Comments

Post a Comment

Popular posts from this blog

Use Cases: The Theory

They told me in my CSCI-1275 Systems Analysis and Design course there's a tendency for programmers to just start coding stuff without thinking, and this was nigh on tantamount to total catastrophe. I didn't fully understand this until a little later in the semester. We had just learned about arrays and collections in my CSCI-1630 C# Programming I course, and I found this to be a perfect excuse to write a little application that would synthetically divide polynomials . (That's a really great way to master synthetic division, actually, if you're interested in brushing up on that skill. Although my wife still insists the time would have been better spent putting more time into my algebra homework. Two types of people...). At any rate, long story short: I made the program work perfectly, for 3rd degree polynomials that divided evenly. Then I realized it broke when I tried a polynomial of the 4th degree. And then again when the 3rd degree polynomial had a remainder. ...
Post a Comment
Read more

Sequence Diagrams: Theorizing

The activity diagram is all well and good, and can even be super useful in a lot of cases. But for my money, so far in my limited experience, the sequence diagram is where you really start to get a handle on what you need to do as a programmer. Before the sequence diagram, you're dealing with steps in a process. What needs to happen, in what order, and you could just as easily be talking about employees or way stations or widgets or nothing at all. They're really about systems analysis--that high level, what needs to happen kind of stuff. Really important work, but totally dull from a programmer standpoint. The sequence diagram is where we start seeing method names and parameters being laid out. The interaction between classes and layers. You start to see what methods you'll need, in what classes, and get a feel for what properties those classes will need. You can see the flow of the data from the start of the operation to the end, note the inputs and the outputs. I...
Post a Comment
Read more

Activity Diagram: Theory

So I've got use cases figured out. Not all of them--only a fool or a genius thinks he can sit at a desk away from the end user and think he's got all the use cases figured out (and a genius would never truly believe it). But you can't sit around trying to anticipate every possible use case before you start, so once we have enough to cobble together a complete program or part of one we can move on for a bit. Side note, this is the beauty of the agile approach: "Yeah, we know we gotta go to the moon. But we have to do it in 10 years, so we can't spend 5 years thinking up every problem we might need to solve before we start solving them. How about we start with 'design a rocket that reaches orbit without killing anyone' and build on that when we finish?" That's called an iteration, but more on that later. Fleshing out what that use case needs is the next step, and there are a couple tools I remember being taught. One of them is the activity diagra...
Post a Comment
Read more