На основании документации из dotenv вы не используете метод config , который считывает и анализирует содержимое из вашего файла .env
. 116]
Кстати, поскольку вы имеете дело с веб-пакетом, я бы предложил использовать пакет dotenv-webpack . Данная документация показывает пример базовой конфигурации вместе с некоторыми другими возможными аргументами.
Если вас интересуют другие способы настройки переменных среды, в частности, в React, я рекомендую эту детальную статью.
Я нашел шаблон, который, на мой взгляд, работает лучше всего - по крайней мере, в моем случае.
Я расширяю классы сущностей, используя частичные классы. Я использую частичные классы, поэтому подпись объекта не меняется (см. Вызов DeleteOnSubmit
в методе Delete
).
Я приготовил небольшой пример. Вот изображение базы данных и настройки класса LINQ to SQL:
А вот частичный класс, в котором я реализую бизнес-логику:
/// <summary>
/// This class extends BusinessLogicDataContext.Products entity class
/// </summary>
public partial class Product
{
/// <summary>
/// New up a product by column: dbo.Products.ProductId in database
/// </summary>
public Product(Int32 id)
{
var dc = new BusinessLogicDataContext();
// query database for the product
var query = (
from p in dc.Products
where p.ProductId == id
select p
).FirstOrDefault();
// if database-entry does not exist in database, exit
if (query == null) return;
/* if product exists, populate self (this._ProductId and
this._ProductName are both auto-generated private
variables of the entity class which corresponds to the
auto-generated public properties: ProductId and ProductName) */
this._ProductId = query.ProductId;
this._ProductName = query.ProductName;
}
/// <summary>
/// Delete product
/// </summary>
public void Delete()
{
// if self is not poulated, exit
if (this._ProductId == 0) return;
var dc = new BusinessLogicDataContext();
// delete entry in database
dc.Products.DeleteOnSubmit(this);
dc.SubmitChanges();
// reset self (you could implement IDisposable here)
this._ProductId = 0;
this._ProductName = "";
}
}
Использование реализованной бизнес-логики:
// new up a product
var p = new Product(1); // p.ProductId: 1, p.ProductName: "A car"
// delete the product
p.Delete(); // p.ProductId: 0, p.ProductName: ""
Кроме того: классы сущностей LINQ to SQL очень открыты в природе. Это означает, что свойство, соответствующее столбцу dbo.Products.ProductId , реализует как геттер, так и сеттер - это поле нельзя изменять.
Насколько мне известно, вы не можете переопределить свойства, используя частичное классы, поэтому обычно я реализую менеджер, который сужает объект с помощью интерфейса:
public interface IProduct
{
Int32 ProductId { get; }
void Delete();
}
Я склонен использовать шаблон Репозитория для инкапсуляции DataContexts.
Я хотел бы найти лучший способ испустить ПОСТЕПЕННО объекты от моего слоя данных при использовании LINQ2SQL все же.
Прямо сейчас я пытаюсь использовать LINQ для классов объекта SQL как бизнес-объекты, раздать их между функциями и сервисами.
Конечно, у Вас должны быть отдельные классы объекта для доступа к базе данных, таким образом, Ваше расположение базы данных может измениться, не изменяя бизнес-объекты!
Я больше всего интересовался бы хорошим решением для этого, также!
Проверьте исходный код для Демонстрационного приложения MVC, которое соединяет Rob Conery:
http://www.codeplex.com/mvcsamples/
У него есть отдельный слой объекта, который отображается на LINQ к классам SQL.
Я сделал некоторое использование экспериментирования Entity Framework и Linq к Объектам как способ далее разделить мой клиентский код от базы данных, но я нашел это неуклюжим для использования и волновался по поводу производительности.
В моем текущем проекте я использую Linq для SQL как мой слой данных, но имею отдельные классы, где я реализую все запросы Linq. Классы возвращают объекты, определенные в моем Linq к контексту SQL, но запросы скрыты в методах.
Я нашел статьи Ian Cooper на CodeBetter.com и ряде Stephen Walther неоценимыми в понимании потребности записать ПОСТЕПЕННО объекты сначала и затем отобразить их на базу данных вместо того, чтобы делать его наоборот (который является тем, что я всегда раньше делал).
Я играю вокруг с идеей иметь отдельный слой модели OO (лучше поддержка методов OO), но то использование LINQ к SQL под капотом. Идея состоит в том, чтобы иметь XML-файл, который инструмент пользователя будет использовать, чтобы сгенерировать код. Так как LINQ к объектам SQL слишком нарушены для моих предпочтений, я автоматически сгенерирую новые классы для использования в качестве моих объектов, и конечно DataContext будет полностью скрыт для клиентского кода. Сделайте короткий ответ: Создайте новые классы объекта, но используйте базовый LINQ для объектов SQL и DataContext.
Я только что опубликовал пример того, как вы можете структурировать свое приложение, которое использует Linq to Sql для хранения, используя шаблоны IoC и T4.
http://daniel.wertheim.se/2010/03/14/linq-to-sql-how-to-separate-the-entities-and-the-datacontext/