0

I am using FluentNHibernate in my solution. The recommended folder structure from fluentnhibernate documenation is like this:

Entities folder, under which we have POCO classes of the business model. Mappings folder, under which we have the mappings to our data model.

I assume that these two folders would go into a business layer project called "BusinessModel"? See below:

BuessinessModel
    |_ Entities
          |- Student.cs
          |- Course.cs
          |- Faculty.cs
    |_ Mappings
          |- Mappings.cs

And maybe create another project called "DataAccess" which references the BusinessModel project for the data access layer to do the CRUD?

What's the best practice? Any architect there? Thanks.

AK: I read your post at n-layered architecture - BLL, DAL and interfaces. What is best practice? .

Let me quote yours

Taking a "Person" as an example: think about the different data operations associated with a person (Getting all the data for a single person, a collection of shallow data for many persons, CRUD operations, searching, etc) - then design interfaces along logical groupings.

I am trying to understand this. So, you are saying that

  1. In the BLL project, we have this Person class.

  2. Also in the BLL project, we have an interface which declares all data operation methods we will need for the Person object.

  3. Then in the DAL project, we have concrete implementation of the interface we define in BLL.

    Does this sound correct to you? Thanks.

Community
  • 1
  • 1
Stack0verflow
  • 1,148
  • 4
  • 18
  • 42

2 Answers2

1

While it's dangerous to go blindly applying the same architecture to every solution / project; my standard / default approach would be something like this:

High Level

  • we're aiming for 3-Tiers, which we assume are: UI, BL (Business Logic), DA (Data Access).
  • That's going to (probably) be made up of the following 4 logical chunks (think namespaces) of components: Common, UI, BL, DA. Keep in mind that each of these 4 chunks will probably have more than one code level project.
  • Common is where we'll stick things which the other 3 need to share - POCO's for example.

Your Specifics

  • Make BusinessModel (probably as a standalone project) inside Common.
  • Mappings I'm guessing is dependent on the physical data source, so that should go into the concrete DA implementation.

Other Notes

  • Best / common practice is to loosely couple our main chunks (especially the BL and DA); usually using Dependency Injection.
  • This will be achieved by defining Inferfaces, and these interfaces will/can use the POCO's or your BusinessModel entities - from the Common.
Adrian K
  • 9,880
  • 3
  • 33
  • 59
  • Thanks, this is helpful. Do I define interfaces in all layers or only in the DA layer? Pointer to any good article? I know I can google, but I am sure I will dig out a whole bunch and don't know which one helps me the best. – Stack0verflow Sep 14 '11 at 13:56
1

You need to separate the concrete data access from the business layer, preferable to create a business layer with entities (domain model) and repository interfaces.

Then create a concrete implementation of Data access which includes mappings and concrete repositories for data access using fluentnhibernate.

Buessiness |_ Entities |- Student.cs |- Course.cs |- Faculty.cs |_ RepositoryInterfaces |- IStudentRepository.cs |- ICourseRepository.cs

DAL (Concrete - using FluentNHibernate) |_ Mappings |- Mappings.cs |_ Repositories |- StudentRepository.cs |- CourseRepository.cs

Mohamed Abed
  • 5,025
  • 22
  • 31
  • Thanks, MA. This is good. I kinda get an idea. Assuming that I have a small solution such that I have only 1 project per layer, then in the business model, I have POCOs and repository interfaces. So, in the DAL, the concrete repository classes actually implement the repository interfaces defined in the business layer? Could you confirm please? I think this will help me organize my solution structure in the right direction. Thank you again. – Stack0verflow Sep 14 '11 at 14:07
  • Yes exactly you got it right, have POCOs and repository interface in business model, and you have concrete repository concrete classes in the dal project implementing the interface. you can also find many DDD samples that implement this architecture .. check out this solution i have been developing, it is a little more complex but it shall give you an idea http://sellandbuy.codeplex.com/ – Mohamed Abed Sep 14 '11 at 20:34