@magicalclick: Do you run VS on your T100?
As far as cost, Surface 3 has the digitizer from Surface, so that's worth a bit more than something like the T100.
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
I'm trying not to fall too far. :)
The app is what I'd consider "medium-sized". It's going to be about 10 weeks of work. I originally thought it would be small enough to not warrant the extra separation.
Aside from being tied to EF, isn't my data access already in its own layer? I can swap out any EF provider for the default MS SQL and wouldn't have to change any code. I've always thought of the DbContext as a UnitOfWork with the DbSets inside acting as queryable Repositories.
My EF POCOs are business objects and do not represent the DB structure.
I've started moving some of my more businessy code out of the controllers and into the business objects. contract.CreateWorkOrders() for example.
My main fear is over-engineering this piece of software.
Working on an MVC project solo for way too long. I initially thought I didn't need a service layer since the app is limited to essentially CRUD operations. I'm starting to wonder if it makes sense to split things out.
My standard GET controller method creates an instance of a viewmodel class, populates it with any data needed (using direct calls to DbContext) and returns a view.
POST methods take in a viewmodel, get a domain instance from the DbContext, updates any changed properties and saves it back to the DbContext.
I find myself repeating a lot of similar queries and have started hitting a few methods where some business rules are creeping in, e.g. only one row in the set can be marked as default.
Should I make some viewmodel factories? Should I create business services that are thin façades on top of the DbContext? I'm just looking for a bit of guidance.
@kettch:Part of my "leaving for vacation" routine is to go around and unplug everything, turn the thermostat off in the summer or at 50 in the winter, and to turn the water heater to "vacation" mode (basically just keeps it from freezing). So to answer your first question, no. :)
For the second question, waiting an hour or two for the house to get comfortable again is fine with me. In winter, put on a sweater. In summer, turn on a fan. Honestly though, with the curtains closed the house tends to stay under 80F inside on its own, which isn't too far from our daytime 75F setting.
NEST was mildly interesting until I realized that it works with motion detection. We almost never walk in front of the thermostat.
Would I opt for a networked thermostat if I was buying a new one? Yeah, probably. But I wouldn't replace the one I have just to get some mildly convenient features. The other home automation stuff doesn't interest me. Unlocking your door with your phone? That's just waiting to be hacked. If my sibling/neighbor needs to check on the house, I'll give him a key before I leave. My smoke detectors beep when they need a new battery (which will probably last longer if they're not connected to wifi).
Was it an MSDN license? If so, you should be able to log into the MSDN Subscriber site and retrieve a product key (as those are good forever, regardless of your subscription status).
If not, you're out of luck. The good news is that the free Community Edition is pretty full-featured. You should give it a try and see if it meets your needs.