In a layered architecture using Entity Framework, should I return POCO classes from the BLL? (Architecture guidance needed)

Question

I\'ve been reading too much probably and am suffering from some information overload. So I would appreciate some explicit guidance.

From what I\'ve gathered, I can use V

Answer 1

What you're doing is basically the Repository pattern, for which Entity Framework and POCO are a great fit.

So, my ViewModels in my MVVM UI app will be communicating with the above BLL class and exchanging BookInfo instances. Is that okay?

That's exactly what POCO objects are for; there's no difference between the classes that are generated and how you would write them by hand. It's your ObjectContext that encapsulates all the logic around persisting any changes back to the database, and that's not directly exposed to your UI.

I'm not personally familiar with IDataErrorInfo but if right now your entities will only be used in this single app, I don't see any reason not to put it directly in the generated classes. Adding it to the T4 template would be ideal if that's possible, it would save you having to code it by hand for every class if the error messages follow any logical pattern.

Also, if you see something terribly wrong with the way I'm trying to build my BLL, please feel free to offer help in that area too.

This isn't terribly wrong by any means, but if you plan to write unit tests against your BLL (which I would recommend), you will want to change your ObjectContext member to IObjectContext. That way you can substitute any class implementing the IObjectContext interface at runtime (such as your actual ObjectContext), which will allow you to do testing against an in-memory (i.e. mocked) context and not have to hit the database.

Similarly, think about replacing your List with an interface of some kind such as IList or IBindingList or the lowest common denominator IEnumerable. That way you're not tied directly to the specific class List and if your needs change over time, which tends to happen, it will reduce the refactoring necessary to replace your List with something else, assuming whatever you're replacing it with implements the interface you've chosen.