Design question for WinForms (C#) app, using Entity Framework
Posted
by
cdotlister
on Stack Overflow
See other posts from Stack Overflow
or by cdotlister
Published on 2011-01-08T01:43:44Z
Indexed on
2011/01/08
1:54 UTC
Read the original article
Hit count: 511
I am planning on writing a small home budget application for myself, as a learning excercise. I have built my database (SQL Server), and written a small console application to interact with it, and test out scenarios on my database. Once I am happy, my next step would be to start building the application - but I am already wondering what the best/standard design would be. I am palnning on using Entity Framework for handling my database entities... then linq to sql/objects for getting the data, all running under a WinForms (for now) application.
My plan (I've never used EF... and most of my development background is Web apps) is to have my database... with Entity Framework in it's own project.. which has the connection to the database. This project would expose methods such as 'GetAccount()', 'GetAccount(int accountId)' etc.
I'd then have a service project that references my EF project. And on top of that, my GUI project, which makes the calls to my service project. But I am stuck.
Lets say I have a screen that displays a list of Account types (Debit, Credit, Loan...). Once I have selected one, the next drop down shows a list of accounts I have that suite that account type.
So, my OnChange event on my DropDown on the account type control will make a call to the serviceLayer project, 'GetAccountTypes()', and I would expect back a List<> of Account Types. However, the AccountType object ... what is that? That can't be the AccountType object from my EF project, as my GUI project doesn't have reference to it. Would I have to have some sort of Shared Library, shared between my GUI and my Service project, with a custom built AccountType object? The GUI can then expect back a list of these. So my service layer would have a method:
public List<AccountType> GetAccountTypes()
That would then make a call to a custom method in my EF project, which would probably be the same as the above method, except, it returns an list of EF.Data.AccountType (The Entity Framework generated Account Type object). The method would then have the linq code to get the data as I want it.
Then my service layer will get that object, and transform it unto my custom AccountType object, and return it to the GUI.
Does that sound at all like a good plan?
© Stack Overflow or respective owner