Tôi đang cố gắng tìm ra cách sạch nhất để thực hiện việc này."Mẫu" tốt nhất cho Lớp Truy cập Dữ liệu vào Đối tượng Kinh doanh
Hiện nay tôi có một đối tượng khách hàng:
public class Customer
{
public int Id {get;set;}
public string name {get;set;}
public List<Email> emailCollection {get;set}
public Customer(int id)
{
this.emailCollection = getEmails(id);
}
}
Sau đó, đối tượng Email của tôi cũng khá cơ bản.
public class Email
{
private int index;
public string emailAddress{get;set;}
public int emailType{get;set;}
public Email(...){...}
public static List<Email> getEmails(int id)
{
return DataAccessLayer.getCustomerEmailsByID(id);
}
}
Các DataAccessLayer hiện kết nối với cơ sở dữ liệu, và sử dụng một SqlDataReader để lặp qua tập hợp kết quả và tạo các đối tượng Email mới và thêm chúng vào một danh sách mà nó trả về khi hoàn tất.
Vậy tôi có thể cải thiện điều này ở đâu và bằng cách nào?
Tôi có nên có DataAccessLayer thay vì trả lại một DataTable và để nó lên đối tượng Email để phân tích cú pháp và trả lại một Danh sách cho Khách hàng không?
Tôi đoán "Nhà máy" có lẽ là từ sai, nhưng tôi nên có một loại EmailFactory khác để lấy một DataTable từ DataAccessLayer và trả về một Danh sách cho đối tượng Email không? Tôi đoán rằng loại âm thanh dư thừa ...
Thực tiễn này thậm chí có thích hợp để có Email.getEmails (id) của tôi làm phương pháp tĩnh không?
Tôi có thể chỉ cần vứt bỏ bản thân bằng cách cố gắng tìm và áp dụng "mẫu" tốt nhất cho những gì bình thường sẽ là một nhiệm vụ đơn giản.
Cảm ơn.
Theo dõi
Tôi tạo ra một ví dụ làm việc nơi miền đối tượng/kinh doanh của tôi trích ra một hồ sơ khách hàng bởi id từ một cơ sở dữ liệu hiện có. Các tệp ánh xạ xml trong nhibernate thực sự gọn gàng. Sau khi tôi làm theo một hướng dẫn để thiết lập các phiên và kho lưu trữ các nhà máy, kéo các bản ghi cơ sở dữ liệu khá thẳng về phía trước.
Tuy nhiên, tôi đã nhận thấy có hiệu suất rất lớn.
Phương thức ban đầu của tôi bao gồm Thủ tục lưu trữ trên DB, được gọi bởi đối tượng DAL, được phân tích cú pháp tập hợp kết quả thành đối tượng miền/doanh nghiệp của tôi.
Tôi đã kiểm tra phương pháp ban đầu của mình khi lấy 30ms để lấy một bản ghi khách hàng duy nhất. Sau đó tôi đã lập phương thức nhibernate khi lấy 3000ms để lấy cùng một bản ghi.
Tôi có thiếu gì đó không? Hoặc là chỉ có rất nhiều chi phí sử dụng tuyến đường nhibernate này?
Nếu tôi thích sự sạch sẽ của các mã:
protected void Page_Load(object sender, EventArgs e)
{
ICustomerRepository repository = new CustomerRepository();
Customer customer = repository.GetById(id);
}
public class CustomerRepository : ICustomerRepository
{
public Customer GetById(string Id)
{
using (ISession session = NHibernateHelper.OpenSession())
{
Customer customer = session
.CreateCriteria(typeof(Customer))
.Add(Restrictions.Eq("ID", Id))
.UniqueResult<Customer>();
return customer;
}
}
}
Các example I followed đã tôi tạo ra một lớp helper để giúp quản lý các phiên làm việc, có lẽ đó là lý do tại sao tôi nhận được chi phí này?
public class NHibernateHelper
{
private static ISessionFactory _sessionFactory;
private static ISessionFactory SessionFactory
{
get
{
if (_sessionFactory == null)
{
Configuration cfg = new Configuration();
cfg.Configure();
cfg.AddAssembly(typeof(Customer).Assembly);
_sessionFactory = cfg.BuildSessionFactory();
}
return _sessionFactory;
}
}
public static ISession OpenSession()
{
return SessionFactory.OpenSession();
}
}
Với ứng dụng tôi đang làm việc, tốc độ là bản chất. Và cuối cùng, rất nhiều dữ liệu sẽ chuyển giữa ứng dụng web và cơ sở dữ liệu. Nếu phải mất một đại lý 1/3 của một giây để kéo lên một hồ sơ khách hàng như trái ngược với 3 giây, đó sẽ là một hit lớn.Nhưng nếu tôi đang làm một cái gì đó kỳ lạ và đây là một chi phí thiết lập ban đầu một lần, sau đó nó có thể là giá trị nó nếu hiệu suất chỉ là tốt như thực hiện các thủ tục được lưu trữ trên DB.
Vẫn mở để đề xuất!
Đã cập nhật.
Tôi đang loại bỏ tuyến đường ORM/NHibernate của mình. Tôi thấy hiệu suất chỉ là quá chậm để biện minh bằng cách sử dụng nó. Truy vấn khách hàng cơ bản chỉ mất quá nhiều thời gian cho môi trường của chúng tôi. 3 giây so với phản hồi phụ thứ hai là quá nhiều.
Nếu chúng tôi muốn truy vấn chậm, chúng tôi sẽ tiếp tục triển khai hiện tại. Ý tưởng để viết lại nó là tăng đáng kể thời gian.
Tuy nhiên, sau khi đã chơi với NHibernate tuần vừa qua, đây là một công cụ tuyệt vời! Nó không hoàn toàn phù hợp với nhu cầu của tôi cho dự án này.
Barry- Vâng, nó hoạt động tốt như hiện tại. Chỉ có điều tôi có thể nghĩ là có DataAccessLayer của tôi trả về một DataTable, để tôi có thể thực hiện kiểm tra xác nhận trong lớp nghiệp vụ của tôi (ví dụ: đối tượng email) thay vì trong lớp truy cập dữ liệu. –
Ví dụ bạn đã đăng là "mô hình miền thiếu máu" cổ điển. Dựa trên ví dụ của bạn, bạn thậm chí không cần một đối tượng kinh doanh. Một đối tượng kinh doanh nên giữ logic kinh doanh, và của bạn thì không. –