DAL для службы Windows - PullRequest
       2

DAL для службы Windows

1 голос
/ 02 ноября 2011

Я нахожусь в процессе написания службы Windows, которая будет читать XML-файл, сгенерированный периодически, и обновлять БД.Я обычно видел трехуровневую архитектуру в веб-приложениях (презентация, BL & DAL как библиотека классов).У меня есть следующие вопросы

  1. Должны ли мы следовать тому же подходу для настольных приложений / службы Windows?
  2. Нужно ли создавать элементы экземпляра для класса DAL или он должен быть статическим?
  3. Существует ли какой-либо инструмент, который может быстро создать слой DAL для сопоставленной БД?

    Любое руководство будет с благодарностью.

Спасибо.

Ответы [ 2 ]

1 голос
/ 02 ноября 2011

n-уровневая архитектура и другие архитектуры решений дают нам некоторые идеи и зависят от условий проекта, и только одно из этих условий является видом наших проектов.

если вы используете 3-tyre в веб-приложении, это не значит, что оно не используется в других типах проектов.

так что в качестве ответа на первый вопрос я говорю, что n-уровень является хорошим (не лучшим) решением для любого проекта, который имеет транзакции на уровне database.use 3-уровня (даже 4-уровня) и не беспокоится. это общая стратегия для разработки служб Windows

для вашего второго вопроса: да, создайте их. Использование статического метода не является способом создания приложения на основе n-уровневой архитектуры.

на ваш третий вопрос: да, есть.

если вы используете .net framework 2, создайте слой DAL с помощью NHibernate. если вы используете .net framework 3 и 3.5, создайте слой DAL с помощью LinQ. и если вы используете .net framework 4, создайте слой DAL с помощью ADL.net Entity Framework.

0 голосов
/ 02 ноября 2011

Вам не нужно использовать LINQ, NHibertate или Entity.Многие проекты, работающие на .NET 4.0, все еще используют старомодный ADO.NET.

LINQ to SQL - это не то, чем можно гордиться в вашем приложении.Что касается Entity Framework или NHibernate, то они являются API-интерфейсами ORM и имеют свои весьма выгодные сценарии использования, но также имеют крутую кривую обучения и менее эффективны по сравнению с использованием встроенных запросов или хранимых процедур (но предлагают гораздо лучшую расширяемость и удобство обслуживания).,Еще одним преимуществом использования этих библиотек ORM является то, что вам не нужно писать SQL в большинстве случаев, но это может создать некоторые проблемы, если у вас сложные сценарии. И вы можете использовать Entity Framework с .NET 3.5

Если вы знакомы с SQL и в проекте не выделена большая команда, нет ничего плохого в использовании встроенных запросов или хранимых процедур,Или, если хотите, вы можете использовать что-то вроде MyBatis, которая оцифровывает объекты, используя отражение на основе предоставленного XML-файла.(Я думаю, что у них есть инструменты генерации).

Так что, на мой взгляд, если у вас большая база данных, но вы не ожидаете сложных запросов, стоимость изучения Entity Framework оправдана.Но если у вас небольшая база данных, но со сложными запросами, которые где-то уже написаны, было бы огромной ошибкой использовать Entity или NHibernate ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...